This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch
"H . J . Lu" <hjl@lucon.org> writes:
> One more comment, I don't know what you will gain by dlopening
> libgcc_s.so.1, given that those functions are also available in
> libc.so.
Calling exactly one implementation all the time is a good thing. Even
if the code exists in multiple places.
Also, we will sometime later add a change which will allow compiling
glibc without compatibility with old C++ ABIs. Then we need the
dlopen code anyway.
> You can't say which ones are newer at the run-time, those
> in libc.so or those in libgcc_s.so.1. I believe we should do a
> run-time/link-time version check of those functions instead.
This is very easy. libgcc_s uses symbol versioning. The symbols used
by symbol versioning are visible though dlsym. So, before getting the
function pointers the code should try to get the symbol "GCC_3.0" (or
whatever the symbol version is which corresponds to code which is in
glibc itself. If the symbol exists, use the libgcc_s. Otherwise use
the internal functions.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------