[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Compiling with MinGW

From: matthew
Subject: Compiling with MinGW
Date: Fri, 4 Aug 2006 11:12:20 -0700

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:


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'


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;;

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
for deplib in $libs; do # right after this line.
        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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]