GNOME Bugzilla – Bug 583657
A patch to build static libraries correctly under MinGW
Last modified: 2009-05-31 21:33:10 UTC
Please describe the problem: Glibmm fails to build static libraries under mingw. The problem is described at http://thread.gmane.org/gmane.comp.gnome.gtkmm/20718 . Basically, invalid static libraries are built because of the DLL-specific symbol decorations, thus preventing normal linking against a static library. I'm attaching a patch (against master branch) which fixes the problem by defining *MM_DLL macros only when not building a static library. Note that you can build either static or shared versions, but not both in the same build directory (I don't think that's possible at all). So, to build static libraries, you have to invoke configure with "--disable-shared --enable-static" options. When building both versions together, no decorations are applied. This configuration didn't work before anyway (), and I'm not sure about the effects of undecorated symbols in case of DLLs. The patch has no effect on cygwin or MSVC, as I don't have any ability to perform the needed tests on these platforms. Only glibmm seems to be affected. I was able to build libsigc++, cairomm, pangomm and gtkmm statically without any patches, and link an executable against them. P.S. I tested the patch (with minor modifications) with glibmm 2.18, as I'm currently unable to build unstable glib (which is required by master branch) under mingw cross-compiler. Steps to reproduce: 1. Run configure --disable-shared --enable-static under mingw. Actual results: Expected results: Does this happen every time? yes Other information:
Created attachment 135242 [details] [review] A patch that fixes the bug
I'm not convinced that a static glibmm library is a particularly good idea, but I doubt this can hurt much. Thans. I'd be interested to know what you need it for. I'll let Armin review the patch because he's doing Windows stuff.
Well, from the top of my head, I can give you two reasons: 1. The zip distribution of my program went down from 2.9MB to 1.7MB. I would say that's a nice improvement. 2. For some reason, purify refuses to load *mm dlls (no such problems with gtk dlls). Having a statically linked binary allows people to analyze it with purify (well, to some extent, as you still have to manually match the instruction pointer addresses with function names), adding a nice tool to the mingw stack (which really lacks this kind of tools), and improving security/stability of the program, etc... There's also the minor bonus of having a single binary, instead of a binary and a bunch of dlls. My program won't be able to use the system-installed glibmm/gtkmm anyway, due to different C++ ABI (I use gcc 4.4, and there are at least 5 incompatible ABI versions I can think of right now). So, I don't really see a point in dragging eight or so dlls just for a single binary.
(In reply to comment #0) > Only glibmm seems to be affected. I was able to build libsigc++, cairomm, > pangomm and gtkmm statically without any patches, and link an executable > against them. For gtkmm, was this after you patched glibmm already or before? I can't build gtkmm statically, either. However, since it also checks for GLIBMM_DLL being defined for the symbol declarations, this doesn't surprise me. Currently, this would mean that if glibmm is built statically, then gtkmm needs to be built statically as well, and vice versa.
I built static gtkmm after installing static glibmm and friends. I didn't try building dynamic gtkmm with static glibmm, but looking at the source code, I guess you're right. If this is a problem, I guess gtkmm could be patched too to use / define GTKMM_DLL instead of GLIBMM_DLL.
(In reply to comment #5) > If this is a problem, I guess gtkmm could be patched too to > use / define GTKMM_DLL instead of GLIBMM_DLL. I did this, and also applied your patch to glibmm. Thanks.