[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-guile-ncurses] Building guile-ncurses on MS-Windows using MinGW
From: |
Mike Gran |
Subject: |
Re: [Bug-guile-ncurses] Building guile-ncurses on MS-Windows using MinGW |
Date: |
Wed, 24 Sep 2014 09:01:21 -0700 |
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