GNOME Bugzilla – Bug 163914
[CYGWIN] libgdk/libuuid link failure
Last modified: 2005-07-28 22:00:35 UTC
When linking on Cygwin with GTK+ 2.6.1, and #163813 has been applied, the link sliently fails due to failing to link libuuid dynamically (it's static only). This results in a build failure when linking the broken libgdk with libgtk at a later point. The attached patch gets the linker to link libuuid, avoiding libtool. I'm not sure this is the best solution (it may be a libtool bug), but it does work... I can recreate a transcript of the failure, if required. libtool tries to create a static library when it can't find a libuuid DLL, but fails. It creates gdk/libgdk-win32-2.0.la, but the actual binary is missing all symbols. Regards, Roger
Created attachment 35935 [details] [review] gtk-2.6.1-configure-uuid.diff Link libuuid directly using ld rather than libtool
163813? You mean bug #163136 ? Yeah, libtool sucks most of the time, especially running it under Cygwin (or MSYS) on Windows. Slooowwww, and often gets things wrong, at least in the context of GLib, GTK+ etc where we always build DLLs, and there absolutely never should be any reason for "relinking". (The first thing I do after untarring a GLib/GTK+/etc tarball to build, is edit ltmain.sh and comment out the place where it sets need_relink to true.) One should whack together a quick libtool-emulating *program* for Windows. One would then run configure as normally, let it create the libtool script, yadda yadda, but then just plonk said program in its place...) Aah, my build speed would at least quadruple. gcc is quite snappy even on my ancient box, but all the (Cygwin-emulated) forking in libtool kills speed.
The speed issue is a killer. It took *16 hours* to build 2.6.0 on a Window98 machine, and it seemed to spend most of the time running sed!! Cygwin on Windows XP, in comparison has much improved fork() performance--it's at least an order of magnitude faster, though still noticably slower than Linux (down to 2 hours). It still only takes 30 minutes on a much slower Debian system though! I'm not sure -Wl,-luuid is the correct solution. I'm seeing gtk-demo segfault in gtk_main, and I haven't found the cause yet (using the win32 backend); the outline and gray background of the main window appears for a fraction of a second. It may be unrelated, but I'll do a bit more testing first. Unfortunately, gdb just prints "??" for the two frames above gtk_main, giving no indication of what went wrong, or where. gdb on Cygwin seems rather less useful than on Linux... Regards, Roger
BTW, for a huge improvement to libtool speed on Windows, see http://www.cs.umu.se/~c00ron/libtool-cache/
Problems like this pop up now and then unexpectedly for me, too. IIRC, often a solution is to create manually a .la file in mingw's lib directory, pointing to the static archibe ("old_library"). No real understanding why this helps.
HEAD of GTK+ now uses -Wl,-luuid.