Re: [Bug-guile-ncurses] Building guile-ncurses on MS-Windows using MinGW

[Mike Gran]

I incorporated some of your suggestions, and I'll roll a new
release once I can get around to verifying that a few more
combinations of operating systems and ncurses versions still build.
 

> I've built guile-ncurses 1.4 today natively on MS-Windows using
> MinGW.  Here are the problems I discovered:
> 
> 1. Compilation fails in ncurses/:
> 
>      /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I..  
> -I ../lib -Id:/usr/include/guile/2.0 -Id:/usr/include      -DGUCU_DLL 
> -DGUCU_DLL_EXPORTS   -g -O2 -MT libguile_ncurses_la-unicode.lo -MD -MP -MF 
> .deps/libguile_ncurses_la-unicode.Tpo -c -o libguile_ncurses_la-unicode.lo 
> `test 
> -f 'unicode.c' || echo './'`unicode.c
>      libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I ../lib 
> -Id:/usr/include/guile/2.0 -Id:/usr/include -DGUCU_DLL -DGUCU_DLL_EXPORTS -g 
> -O2 
> -MT libguile_ncurses_la-unicode.lo -MD -MP -MF 
> .deps/libguile_ncurses_la-unicode.Tpo -c unicode.c  -DDLL_EXPORT -DPIC -o 
> .libs/libguile_ncurses_la-unicode.o
>      unicode.c:30:22: fatal error: langinfo.h: No such file or directory
>      compilation terminated.
> 
>    This is because MinGW doesn't have langinfo.h and the nl_langinfo
>    function which unicode.c wants to use.  I suggest to import the
>    nl_langinfo module from gnulib to solve this (I did that manually
>    to overcome this problem).


I replaced the langinfo call with a GetACP call on Windows.

> 
> 2. Link failure in ncurses/:
> 
>      .libs/libguile_ncurses_la-form_type.o: In function `print_form':
>      guile-ncurses-1.4\ncurses/form_type.c:372: undefined reference to 
> `asprintf'
>      .libs/libguile_ncurses_la-form_type.o: In function `print_field':
>      guile-ncurses-1.4\ncurses/form_type.c:204: undefined reference to 
> `asprintf'
>      .libs/libguile_ncurses_la-menu_type.o: In function `print_item':
>      guile-ncurses-1.4\ncurses/menu_type.c:173: undefined reference to 
> `asprintf'
>      .libs/libguile_ncurses_la-menu_type.o: In function `print_menu':
>      guile-ncurses-1.4\ncurses/menu_type.c:318: undefined reference to 
> `asprintf'
>      .libs/libguile_ncurses_la-panel_type.o: In function `print_panel':
>      guile-ncurses-1.4\ncurses/panel_type.c:186: undefined reference to 
> `asprintf'
>      .libs/libguile_ncurses_la-type.o:
>      guile-ncurses-1.4\ncurses/type.c:1030: more undefined references to 
> `asprintf' follow
>      collect2.exe: error: ld returned 1 exit status
> 
>    This is because MinGW doesn't have asprintf.  Again, importing the
>    asprintf module from gnulib should solve this.

I replaced all cases of asprintf with snprintf.

> 
> 3. Compilation error in tools/:
> 
>      gcc -DHAVE_CONFIG_H -I. -I..  -Id:/usr/include/guile/2.0 
> -Id:/usr/include  
> -I ../lib  -DLOCALEDIR=\"d:/usr/share/locale\"      -g -O2 -MT 
> shell.o -MD -MP -MF .deps/shell.Tpo -c -o shell.o shell.c
>      shell.c:37:21: fatal error: termios.h: No such file or directory
>      compilation terminated.
>      Makefile:451: recipe for target `shell.o' failed
>      make[2]: *** [shell.o] Error 1
> 
>    The shell program is entirely unportable to native MS-Windows, and
>    needs X to run anyway.  I solved this by using "make -k" to build
>    regardless.  I think the build process should simply not build the
>    shell on MinGW.

Done.

> 
> 4. "make install-strip" disregards prefix= and installs the Scheme
>    files into the $prefix/ tree.  This is a minor annoyance, as I'm
>    used to creating a binary distro like this:
> 
>      make install-strip prefix=/foo/bar
> 
>    where /foo/bar is an empty directory.  Then I have a tree with
>    distributed files ready to be tarred under /foo/bar.  In
>    guile-ncurses, all the products are installed under /foo/bar,
>    except the *.scm files, which are installed under $prefix as
>    specified during the configure step.
> 
>    Solution: move by hand to the installation directory.

Likely won't fix, because autotools are scary.

> 
> 5. The shared library is installed into incorrect directory.
> 
>    It is installed in $prefix/lib, which is wrong for Windows: the
>    shared libraries on Windows should be installed into $prefix/bin.

Updating autotools seems to fix this problem, as far as I can tell.

> 
> 6. Trying to use the hello world program, Guile cannot load the
>    guile-ncurses DLL:
> 
>      While executing meta-command:
>      ERROR: In procedure dynamic-link: file: "libguile-ncurses", 
> message: "The specified module could not be found."
> 
>    This is because it looks literally for libguile-ncurses.dll,
>    without the version number, whereas the shared library that is
>    installed is called libguile-ncurses-8.dll.  I hacked curses.scm to
>    use libguile-ncurses-8 instead (and likewise with other *.scm
>    files), but I think there should be a better solution to this
>    issue.  Perhaps this is even something to discuss on guile-devel,
>    as it's a general problem with such naive loading of extensions.

An upstream problem, as you noted.

I've defined the LTDL_LIBRARY_PATH=/mingw/lib so that libtools
looks for the .la files, which contain the paths to versioned dlls
in /mingw/bin

> 
> 7. A lot of warnings when curses.scm is auto-compiled the first time
>    it is loaded into Guile:
> 
>      ;;; ncurses/curses.scm:1116:36: warning: possibly unbound variable 
> `%acs-block'
>      ;;; ncurses/curses.scm:1117:36: warning: possibly unbound variable 
> `%acs-board'
>      ;;; ncurses/curses.scm:1118:36: warning: possibly unbound variable 
> `%acs-btee'
>      ;;; ncurses/curses.scm:1119:36: warning: possibly unbound variable 
> `%acs-bullet'
>      ;;; ncurses/curses.scm:1120:36: warning: possibly unbound variable 
> `%acs-ckboard'
>      ;;; ncurses/curses.scm:1121:36: warning: possibly unbound variable 
> `%acs-darrow'
> 
>    etc.
> 
>    These don't happen when I compile the *.scm files with guild.
> 
>    Btw, I suggest to compile the *.scm files at "make install" time.

I know it is annoying, but, I probably won't fix this until the
platforms and distros I care about have all moved to Guile 2.0.x in
their stock install.

Thanks,

Mike Gran