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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
