This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch

"H . J . Lu" <> writes:

> One more comment, I don't know what you will gain by dlopening
>, given that those functions are also available in

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 or those in 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   `------------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]