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
On Fri, Dec 10, 2004 at 06:40:19PM +0000, Mike Hearn wrote:
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
Correct. I documented this problem in the compiling docs on the Wiki:
http://inkscape.org/cgi-bin/wiki.pl?CompilingStatic
Edit os_dep.c, and replace the __libc_stack_end pragma/extern with "ptr_t __libc_stack_end = 0;" This symbol doesn't link when going static.
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.
From the research I did, the glibc folks do NOT want this symbol
exported. It was debated, and in the end it seemed that they marked it up in a way that it can't be linked against now.
On Fri, 10 Dec 2004 11:16:47 -0800, Kees Cook wrote:
Correct. I documented this problem in the compiling docs on the Wiki:
Ah, I didn't know about this document. Thanks.
-mike
On Fri, Dec 10, 2004 at 09:43:36PM +0000, Mike Hearn wrote:
Ah, I didn't know about this document. Thanks.
Sure thing. It's linked off of the more general http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape page, which is linked to the main Wiki page. People have been keeping distro, etc specific notes in there and below.
On Fri, 10 Dec 2004, Mike Hearn wrote:
ask for an explanation of this mess from the glibc developers (I will probably be ignored)
It's going to be a painful day in Linux when glibc is forked or replaced, but if things continue to go the way they have been, it will eventually happen.
Hopefully not by one of the commercial distro vendors, but they are the most likely to get fed up with this stuff and other undifferentiated insanity.
-mental
participants (3)
-
Kees Cook -
MenTaLguY -
Mike Hearn