Cross-compiling GlibMM statically to Win32 with MinGW

[Bob Jamison <rjamison titan com>]

Hi, all.

I am one of the guys working on the Inkscape (SVG editor) project,
and I am one of the people who do the builds of Inkscape on Win32.

Recently, we have started refactoring our code from Gtk/Glib to
GtkMM/GlibMM.  On the Win32 side, we are running into a problem
with GlibMM.

We use Boehm-GC for automatic garbage collection of memory.  In
the Unix/Linux world, this presents no great obstacles to using GlibMM.

But on Win32, there is a basic problem when memory is allocated in
one manner in the executable, and freed in a DLL, maybe in another fashion.
The converse, DLL--->exe, also applies.    The separation of address spaces
between the executable and any DLLs it might be using causes segfaults on
Win32 where there would otherwise be no problem.  Thus we cannot use
GtkMM/GlibMM DLLs, and must link statically.   For the most part,
building these static libs on the cross-compiler is no problem.

But for GlibMM, there are several places where the #ifdefs favor dynamic
linking over static, when Win32 compilation is in effect.  It seems that the
switches assume that a Win32 user will of course want DLLs, and not 
static libs.
I have been able to hack a few files to get the compilation to be 
static.  Not only
the .cc's , but the defs in the .h's need to be static,  for any client 
software calling
them.  I have had luck by hacking these files:

glibmmconfig.h:
#undef GLIBMM_DLL
#define GLIBMM_API
this is obviously a hack.  I am sure I could have done it more cleanly

quark.h:
remove GLIBMM_API at the bottom, at the definition of the extern vars

container.h:
same thing, for null_pointer


...and a silly hack to make it compile:
thread.cc and ustring.cc
add at top of file, before #includes,
#define GLIB_VAR extern __declspec(dllimport)




Maybe I am the first user who needs static libs on Win32?  Probably!  ^^
I always do things the hard way.

I have always preferred using .def files over dllimport or dllexport.
The separation of code and its disposition has always been a lot
cleaner for me.

Anyway, I hope that this explanation has not been too confusing.
If you have any ideas, thanks in advance.


By the way.. I just -LOVE-   Glib::ustring.  It has been incredibly
helpful with our localization code.



Bob Jamison
Titan Corp.