After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 163914 - [CYGWIN] libgdk/libuuid link failure
[CYGWIN] libgdk/libuuid link failure
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.6.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on: 163913
Blocks:
 
 
Reported: 2005-01-13 09:52 UTC by Roger Leigh
Modified: 2005-07-28 22:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtk-2.6.1-configure-uuid.diff (452 bytes, patch)
2005-01-13 09:52 UTC, Roger Leigh
none Details | Review

Description Roger Leigh 2005-01-13 09:52:07 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
Comment 1 Roger Leigh 2005-01-13 09:52:58 UTC
Created attachment 35935 [details] [review]
gtk-2.6.1-configure-uuid.diff

Link libuuid directly using ld rather than libtool
Comment 2 Tor Lillqvist 2005-01-13 10:19:30 UTC
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.
Comment 3 Roger Leigh 2005-01-13 12:21:20 UTC
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
Comment 4 Tor Lillqvist 2005-02-02 17:36:52 UTC
BTW, for a huge improvement to libtool speed on Windows, see
http://www.cs.umu.se/~c00ron/libtool-cache/ 
Comment 5 Tor Lillqvist 2005-02-02 17:49:58 UTC
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.
Comment 6 Tor Lillqvist 2005-07-28 22:00:35 UTC
HEAD of GTK+ now uses -Wl,-luuid.