GNOME Bugzilla – Bug 699673
[3.2/3.4/3.6/3.8] uuid conflicting on Windows
Last modified: 2013-07-13 14:16:03 UTC
In the gtk/Makefile.am file, gtk+ forced link libuuid: libgtk_3_la_LDFLAGS += -Wl,-luuid But in the file gdk/win32/gdkdnd-win32.c, gtk+ forced uuid initialization: #define INITGUID Then we got lots of FOLDERID_* redefined errors when link. I think '#define INITGUID' should be replaced with '#undef INITGUID'. Then I can build gtk+ 3.2.4 and 3.4.4 success by mingw-w64 gcc.
*** Bug 699672 has been marked as a duplicate of this bug. ***
mingw-fedora fix has the following comment: http://pkgs.fedoraproject.org/cgit/mingw-gtk2.git/commit/?id=3224e445dad240da5f5ebfe371e8c9f627459089 As of mingw-w64 r5589 the header knownfolders.h was added which contains definitions like FOLDERID_Windows As these are also part of libuuid.a you'll get linker failures like: /usr/i686-w64-mingw32/sys-root/mingw/lib/libuuid.a(lib32_libuuid_a-uuid.o):(.rdata+0x0):multiple definition of `FOLDERID_Windows' win32/.libs/libgdk-win32.a(gdkdnd-win32.o):gdkdnd-win32.c:(.rdata+0x360):first defined here Workaround this for now until mingw-w64 upstream has come up with a statement whether this is expected behaviour and what component should be fixed exactly
Created attachment 244007 [details] [review] Do not define INITGUID Defining INITGUID causes a build failure with mingw-w64 > r5589. Documentation on INITGUID is unclear, but it seems you should only define INITGUID when building a Windows driver.
I have tested patch 244007 with mingw-w64, both with version < r5589 and with version > r5589 and gtk compiles works with it. However, before applying it to master, it would be good to know if it also works with the original mingw compiler and with MSVC. Anyone that can test those?
Since documentation is unclear, i'll try to explain my understanding if the GUID madness. AFAIU, it's simple: the goal is to have one header for both the library that defines GUID, and for headers that other programs use to link to that library. Therefore the macro that defines GUID in a header behaves differently depending on whether it's being used by the library that exports the GUID, or by programs. The macro controlling _that_ is INITGUID. If it's defined, then the code thinks itself a library (i.e. libuuid) and defines the GUID variable. Otherwise the code just declares it extern and must be linked to the library that defined GUID. The correct use of INITGUID is to have a single source file in a library define INITGUID before including the header with DEFINE_GUID() macro invocations. That source file will define the GUID. All other source files should not define INITGUID, just include the header - they'll refer to the extern variable that that single source file defines. 3rdparty applications should also not use INITGUID, just include the header. Why did it work with mingw.org headers and libraries? Because they don't have the GUIDs exported from a library (but did have correct DEFINE_GUID invocations in their headers), so GTK had to define INITGUID to get these GUIDs. If you want to keep mingw.org compatibility, i'd advise to explicitly check for mingw.org headers and define INITGUID if they are being used.
(In reply to comment #5) > The correct use of INITGUID is to have a single source file in a library define > INITGUID before including the header with DEFINE_GUID() macro invocations. So is it correct that the definition of INITGUID is only relevant if GTK uses DEFINE_GUID() anywhere? Currently, GTK does not seem to use DEFINE_GUID(), thus it would be safe to just remove '#define INITGUID', right?
Yes, if libuuid defines the GUIDs, then the right thing to do is to remove INITGUID from GTK. If it doesn't (i.e. it's libuuid from mingw.org, not mingw-w64), then INITGUID must stay (otherwise you'll have undefined references).
(In reply to comment #7) > Yes, if libuuid defines the GUIDs, then the right thing to do is to remove > INITGUID from GTK. > > If it doesn't (i.e. it's libuuid from mingw.org, not mingw-w64), then INITGUID > must stay (otherwise you'll have undefined references). I am confused! Are you saying for mingw.org compatibility we should do something like: #if defined(MINGW32) && !defined(MINGW64_VERSION_MAJOR) #define INITGUID #endif or can we completely remove '#define INITGUID' from GTK, because GTK is not using DEFINE_GUID() itself?
do something like: #if defined(MINGW32) && !defined(MINGW64_VERSION_MAJOR) #define INITGUID #endif (just be careful to use MINGW64_VERSION_MAJOR only after including some CRT header; that macro is not defined by gcc, it's defined by internal _mingw.h, which is included by most C header files that mingw-w64 supplies).
(obviously, i meant __MINGW64_VERSION_MAJOR)
(In reply to comment #9) > do something like: > > #if defined(MINGW32) && !defined(MINGW64_VERSION_MAJOR) > #define INITGUID > #endif What about MSVC? Does it need INITGUID? Or is this basically an mingw.org specific work around?
It's MS-specific, see [1] [1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd375463%28v=vs.85%29.aspx
Created attachment 244107 [details] [review] Define INITGUID only for mingw.org compiler After valuable input from LRN, I've updated my patch to only define INITGUID for the mingw.org compiler. Defining INITGUID causes a build failure with mingw-w64 > r5589. With this patch, for the mingw-w64 compiler and other comilier like the MSVC compiler INITGUID is no longer defined.
Review of attachment 244107 [details] [review]: Hi, Sorry I was not able to test this patch earlier as I was away from my work computer for a few weeks. The patch does build and run fine with Visual C++ 2008 and 2010, without any related warnings. With blessings.
Attachment 244107 [details] pushed as 6a71820 - Define INITGUID only for mingw.org compiler
This bug also exists on the 2.24 branch. Could someone please cherry-pick 6a71820 from master to 2.24?
(In reply to comment #16) > This bug also exists on the 2.24 branch. Could someone please cherry-pick > 6a71820 from master to 2.24? Cherry-picked for 2.24 with commit c8d52c018b33b13498c53b607acb1347db249a26.