Compiling with MinGW

[matthew jenika com]

This is not exactly a bug in a strict since but it is a complication  
of building software with MinGW. Just a little back ground I was  
looking to build the latest version of wvware so that I end up with a  
windows stand alone binary.

The environment that I was working on was:

Windows 2003
Cygwin Current (make, pkgconfig, autoconf, automake)
Installed MingGW using auto installer MinGW-5.0.3

Given the above I downloaded and built each of the following:

zlib-1.2.3.tar.gz     http://www.zlib.net/zlib-1.2.3.tar.gz
libiconv-1.11.tar.gz  http://mirrors.usc.edu/pub/gnu/libiconv/ 
libiconv-1.11.tar.gz
libxml2-2.6.26.tar.gz ftp://xmlsoft.org/libxml2/libxml2-2.6.26.tar.gz
gettext-0.15.tar.gz   http://mirrors.usc.edu/pub/gnu/gettext/ 
gettext-0.15.tar.gz
glib-2.12.1.tar.gz    ftp://ftp.gtk.org/pub/gtk/v2.12/glib-2.12.1.tar.gz
libgsf-1.14.1.tar.gz  http://ftp.gnome.org/pub/GNOME/sources/libgsf/ 
1.14/libgsf-1.14.1.tar.gz
wv-1.2.1.tar.gz       http://prdownloads.sourceforge.net/wvware/ 
wv-1.2.1.tar.gz?download

I was able to get everything to work out in the end however gettext  
and glib packages both gave me difficulties.

The errors they generated are:

GETTEXT:

Making all in libuniname
make[3]: Entering directory `/home/matthew/tmp/wv/gettext-0.15/ 
gettext-tools/libuniname'
/bin/sh ../libtool --tag=CC --mode=link gcc  -g -O2  -Lc:/progra~1/wv  
-Wl,--disable-auto-import -o test-names.exe  test-names.o  
libuniname.a ../lib/libgettextlib.la
gcc -g -O2 -Wl,--disable-auto-import -o .libs/test-names.exe test- 
names.o  -Lc:/progra~1/wv libuniname.a ../lib/.libs/ 
libgettextlib.dll.a /home/matthew/tmp/wv/gettext-0.15/gettext-tools/ 
intl/.libs/libintl.dll.a -Lc:/progra~1/wv/lib
gcc.exe: /home/matthew/tmp/wv/gettext-0.15/gettext-tools/intl/.libs/ 
libintl.dll.a: No such file or directory
make[3]: *** [test-names.exe] Error 1
make[3]: Leaving directory `/home/matthew/tmp/wv/gettext-0.15/gettext- 
tools/libuniname'


GLIB:

Making all in gobject
make[2]: Entering directory `/home/matthew/tmp/wv/glib-2.12.1/gobject'
make  all-am
make[3]: Entering directory `/home/matthew/tmp/wv/glib-2.12.1/gobject'
/bin/sh ../libtool --mode=link gcc  -g -O2 -mms-bitfields -Wall  -Lc:/ 
progra~1/wv/lib -o gobject-query.exe  gobject-query.o ./ 
libgobject-2.0.la ../glib/libglib-2.0.la -lintl
gcc -g -O2 -mms-bitfields -Wall -o .libs/gobject-query.exe gobject- 
query.o  -Lc:/progra~1/wv/lib ./.libs/libgobject-2.0.dll.a /home/ 
matthew/tmp/wv/glib-2.12.1/glib/.libs/libglib-2.0.dll.a ../glib/.libs/ 
libglib-2.0.dll.a -lws2_32 -lole32 c:/progra~1/wv/lib/libintl.dll.a  
c:/progra~1/wv/lib/libiconv.dll.a -Lc:/progra~1/wv/lib
gcc.exe: /home/matthew/tmp/wv/glib-2.12.1/glib/.libs/ 
libglib-2.0.dll.a: No such file or directory
make[3]: *** [gobject-query.exe] Error 1
make[3]: Leaving directory `/home/matthew/tmp/wv/glib-2.12.1/gobject'


Both of the above errors are caused because of the environment the  
software is being built in and how libtool interacts. The basic  
problem is gcc for MinGW does not know how to properly handle cygwin  
paths. libtool is automatically generating a fully qualified path  
using cygwin based paths. I didn't spend a lot of time digging into  
what the right solution for libtool might be but found that by simply  
editing the libtool used in both of the above cases and adding:

        case $deplib in
          /home*) deplib="c:/cygwin"$deplib;;
        esac

just after the for loop on line 2459 gettext and line 2363 of glib  
(that area looks something like this)

      if test "$pass" = dlopen; then
        # Collect dlpreopened libraries
        save_deplibs="$deplibs"
        deplibs=
      fi
      for deplib in $libs; do                    # right after this  
line.
        lib=
        found=no
        case $deplib in

I was able to complete the compiles and generate a version of  
wvware-1.2.1 that worked standalone on windows.

If a good option can be found to make this issue go away it would be  
nice but it is a somewhat unusual configuration. But, I thought I  
would pass it along just in case someone else might be interested.

Matthew McGillis