Re: Problems compiling/running Win32 console application with ncurses

[Thomas Dickey]

On Wed, Jul 03, 2013 at 01:04:31PM +0000, BENARD Olivier wrote:
> Hello,
> 
> I'm currently trying to port a little Win32 console application that is using 
> PDCurses to using ncurses to see if it would fix a problem I have with 
> mvaddch() displaying characters a pixel too short when using colors (you can 
> follow all my struggle here: 
> http://angband.oook.cz/forum/showthread.php?t=5481). After a few tries with 
> the current 5.9 release (20110404), I managed to pull something that works 
> fine (using MinGW). My only problem is that my application displays wide 
> characters (like 0x2591 for semi-solid blocks) and the 20110404 version 
> doesn't support wide characters.
> 
> Since an experimental wide character support has been implemented in the 
> latest patches, I downloaded the mingw32-20130622 package, plugged the 
> include and lib files in my source code and recompiled. Unfortunately, the 
> following linker errors occurred:
> 
> -          Unresolved external '_nodelay'
> -          Unresolved external '_cbreak'

Those are surprising, since they are used by the test-programs (which link 
without complaints).
They are low-level functions, which do have the potential for being overlooked.

> Removing calls to nodelay() and cbreak() from my code made it compile, but 
> the first call to keypad() crashed the program...
> 
> So I decided to recompile ncurses using MinGW from the ncurses-5.9-20130622 
> archive following the instructions in the README.MinGW file. Here's the whole 
> procedure I did that worked for me:
> 
> -          Download and install TDM-GCC 4.7.1
> -          Download and install MSYS 1.0.11
> -          Download and unzip LIBTOOL 2.4.2
> -          Build LIBTOOL 2.4.2

Mostly I cross-compile, and build on Windows 7 when I'm debugging something
specific to the MinGW port.

I've not been using libtool in my cross-compiler builds.  There
was some earlier report pointing out a problem with libtool + ncurses + mingw,
but I've not gotten into making that work for cross-compiling...

Here's a fragment from the scripts which I use for building those:

configure --with-build-cc=$BUILD_CC --host=$TARGET --target=$TARGET "$@"
        --with-shared \
        --without-debug \
        --with-trace \
        --disable-hard-tabs \
        --enable-term-driver \
        --enable-sp-funcs \
        --with-fallbacks=unknown,rxvt \
        --with-tparm-arg=intptr_t \
        --without-ada \
 
> o   $ ./configure --prefix=/mingw
> o   $ make
> o   $ make install
> 
> -          Download and unzip the latest patch (ncurses-5.9-20130622)
> -          Set environment variables (TERM=#win32con and PATH_SEPARATOR=;)
> -          Launch MSYS and build NCURSES
> 
> o   $ ./configure \
> --prefix=/mingw \
> --without-cxx \
> --without-cxx-binding \
> --without-ada \
> --enable-warnings \
> --enable-assertions \
> --enable-reentrant \
> --disable-home-terminfo \
> --enable-database \
> --enable-sp-funcs \
> --enable-term-driver \
> --enable-interop \
> --disable-termcap \
> --with-progs \
> --with-libtool \
> --enable-pc-files \
> --enable-widec

My source cross-compiles - except for libtool.
It would be nice if there were a cross-compiling package for that.
 
> o   $ make
> -          Create the libncursestw.lib file from libncursestw-5.dll (I'm 
> using BCC to compile my program, so I used implib there)
> -          Copy the include and lib files into the include and lib folders of 
> my program
> -          Recompile my program using BCC

I've only used gcc and its utilities (I'm aware that different compilers have
different "_" prefix conventions, though the problem with _nodelay might be
a #define conflict someplace).
 
> At this point, things are getting better compared to the mingw32-20130622
> package.  However, I still get the following linker error:
> -          Unresolved external '_delwin'
> 
> Maybe I'm doing something wrong here? Or forgot something?

I'd look at the symbols for the library (using nm or whatever tool works)
to be sure it is exported.
 
> Now if I remove the call to delwin() from my code and recompile, the program
> runs just fine.  Except two little bugs.  First, the wide characters are not
> displayed properly, which probably means that the experimental wide character
> support isn't fully working yet.  For example, the "semi-solid block"
> character ([cid:image001.png@01CE77F0.391D4900] 0x2591) is displayed as a
> "pipe" character ([cid:image002.png@01CE77EF.D6622B50] 0x00A6?).  And the

It depends on the fonts (and the type of console window).
But it's certainly possible that there are remaining bugs -

> second bug, which is more annoying, is that mvaddch() is also displaying
> characters a pixel too short when using colors (same problem as with
> PDCurses).  This happens completely randomly (see the following picture -
> this should be a rectangular form displayed with dark yellow solid block
> characters):

well... The win32 console driver doesn't know about pixels.  It is using
the console api, which works in character cells - no fractions.  I'd consider
the possibility that the underlying console window is trying to infer the actual
width of a given wide-character and is getting confused.
 
> [cid:image003.png@01CE77F4.2130E0A0]
> 
> I recall this problem not being present in older patches (sure doesn't happen
> with the regular 20110404 release).  My last post on angband.oook.cz is from

20110404 doesn't implement much of wide characters (so it would be hard to see
comparable cases).  That was later - I see last October for instance.

> October 15, 2012 and didn't mention the problem, so this has been introduced
> since.  Any idea what could be the cause?

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature