Good day gentlemen,
Statically linking libgc is a good idea, because not many people have this library and it's small enough that doing so isn't a big deal.
Unfortunately due to the general brokenness of glibc, this will fail on some systems with the following error:
inkscape: relocation error: inkscape: symbol __libc_stack_end, version GLIBC_2.1 not defined in file ld-linux.so.2 with link time reference
This is because at some point, __libc_stack_end was changed from being public to private. It seems there's been some to-and-fro on this issue: on a Debian unstable system I have access (glibc 2.3.2) to __libc_stack_end is exported but marked as private, eg you can still build against it and it'll work but may break at any moment. On my inkscape nightly build system (glibc 2.3.4) and on my Fedora Core 3 system it's public (@@GLIBC_2.1).
It appears that this symbol was originally public, made private then it was discovered that it was required for some of the non-exec stack work and made public again. The net result is that anything attempting to use this symbol is going to be screwed by the symbol versioning mechanism.
Boehm GC attempts to weak link against this symbol, but due to the dubious design of weak linkage on GNU systems it fails because glibc does not export this symbol as weak. I will apply a patch to the autopackage copy of libgc soon to make it always fall back to parsing /proc, ask for an explanation of this mess from the glibc developers (I will probably be ignored) and post the patch to upstream libgc to use dlsym to retrieve this symbol, which should bypass symbol versioning.
If anybody sees this message then, now you know what it means (kinda).
thanks -mike