This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Weak versioned symbols?
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>
- Cc: "'Manuel Serrano'" <Manuel dot Serrano at sophia dot inria dot fr>,Hans Boehm <boehm at acm dot org>, "'Kenneth C. Schalk'" <ken at xorian dot net>,"'tromey at redhat dot com'" <tromey at redhat dot com>
- Date: Mon, 28 Apr 2003 16:47:22 -0700
- Subject: Weak versioned symbols?
Ken Schalk and Manuel Serrano pointed out a bug that shows up in my garbage collector. It is also reported in http://bugs.debian.org/165837 .
My garbage collector currently refers to __libc_stack_end as a weak symbol. This symbol is no longer exported in glibc 2.3. I'm referring to it because there isn't yet an adequate replacement in deployed glibc versions, and my fallback algorithm for Linux is slower and relies on /proc, which may not always be available.
The problem is that this appears to generate a runtime error if an executable was linked against glibc 2.2, but is then run in a 2.3 environment. My understanding was that weak symbols were introduced precisely to avoid this problem? What went wrong? Is this related to the patch in http://sources.redhat.com/ml/binutils/2003-04/msg00239.html ?
Thanks for any insight.
Hans
Here's part of Ken's description of what happens:
[Ken:]
...I ran into a thorny issue with __libc_stack_end and different
versions of the GNU libc. The problem I had was exhibited by this
message:
relocation error: symbol __libc_stack_end, version GLIBC_2.1 not defined
in file ld-linux.so.2 with link time reference
Because of the way Vesta works, my builds of the collector (and
everything linking with it) get done in a change-root environment that
can be somewhat different from what's installed on the system I
subsequently run the binaries on. In the case where I saw this, I was
compiling in an environment with a 2.2 GNU libc and running in an
environment with a 2.3 libc.
...
I'm not sure who to pin the blame on, but the symbol does seem to get
resolved at link time (to either "__libc_stack_end@@GLIBC_PRIVATE" or
"__libc_stack_end@@GLIBC_2.1"). At run-time (when the error occurs),
it's definitely no longer a weak symbol.