Weak versioned symbols?

Weak versioned symbols?

[Boehm, Hans]

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.