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 642214 - GTK+ 3.0 fails to compile caused by linking with libuuid.a via libtool in Windows hosts
GTK+ 3.0 fails to compile caused by linking with libuuid.a via libtool in Win...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
3.0.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
: 648975 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-13 08:44 UTC by Arnel Borja
Modified: 2011-05-05 14:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for GTK+ 3 to link libuuid using linker instead of passing to libtool (681 bytes, patch)
2011-02-13 08:44 UTC, Arnel Borja
none Details | Review
Bypass libtool for linking with libuuid on win32 (1.25 KB, patch)
2011-05-01 05:51 UTC, Kalev Lember
committed Details | Review

Description Arnel Borja 2011-02-13 08:44:19 UTC
Created attachment 180763 [details] [review]
Patch for GTK+ 3 to link libuuid using linker instead of passing to libtool

libgtk-3-0.dll fails to compile for Windows hosts because libuuid is linked using libtool instead of passing it to the linker. Libtool only accepts import libraries for shared libraries, while libuuid is a static library in Windows.

Error from libtool:
*** Warning: linker path does not have real file for library -luuid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/i586-mingw32msvc/lib/libuuid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

Removing "-luuid" from libgtk_3_la_LIBADD then adding "-Wl,-luuid" to libgtk_3_la_LDFLAGS when compiling for Windows hosts solves the problem. A patch is attached to do this.
Comment 1 Kalev Lember 2011-05-01 05:41:24 UTC
Thanks for the patch, Arnel. Looks like it's a regression introduced in http://git.gnome.org/browse/gtk+/commit/?id=07d49ee56a4ce86d9d6154e00ff6b10bd3bdc2a4
Comment 2 Kalev Lember 2011-05-01 05:51:16 UTC
Created attachment 186959 [details] [review]
Bypass libtool for linking with libuuid on win32

Arnel Borja's patch formatted with git-format-patch for easy applying.

I also edited the patch slightly to also remove the commented out
#libgtk_win32_3_la_LDFLAGS = $(libtool_opts) -Wl,-luuid
line which was commented out in 07d49ee5 when all the backend libraries were merged into libgtk.
Comment 3 Colin Walters 2011-05-02 14:19:23 UTC
Review of attachment 186959 [details] [review]:

Looks correct to me as far as we're fixing the regression; the old code definitely used the -Wl,-luuid trick.

I'm surprised that libtool doesn't have a mechanism for doing what you want though.
Comment 4 Colin Walters 2011-05-02 14:21:41 UTC
Attachment 186959 [details] pushed as c064808 - Bypass libtool for linking with libuuid on win32
Comment 5 Erik van Pienbroek 2011-05-05 14:37:31 UTC
*** Bug 648975 has been marked as a duplicate of this bug. ***