PATCH: Treat RTLD_LOCAL like Solaris (Re: Duplicate data objects in shared libraries)

[Ulrich Drepper]

On Thu, 2002-05-30 at 13:01, Jason Merrill wrote:

> No; Solaris' behavior is no more helpful for real-world C++ examples.

Very specialized and maybe true for gcc.


> Is there any kind of a standard for ld.so symbol resolution behavior?

Most things the generic ELF ABI covers.  But the behavior of dlopen() on
the ELF level is not covered by any standard.


> 1) Always prefer the last weak definition if no strong definition is seen.

Special weak symbol handling is going away.  The ELF spec didn't clearly
state what has to happen and so a few implementation (like glibc) added
this kind of support.  But it's not portable and it's unnecessarily
reducing the speed.


> 2) If a DSO A has two unrelated dependencies B and C which both define (and
>    use) the same weak symbol, add C to the dependency list of this loaded
>    copy of B.

If I understand this correctly you mean

   A ---> B
     |
     +--> C

and B defines and uses 'foo' and C defines and uses 'foo'.

In this case it makes no difference whether C gets added to the
dependency list of B since B's scope comes first.


> 3) When resolving a relocation from a DSO loaded with RTLD_LOCAL, start
>    looking from the DSO itself; do not consider other RTLD_LOCAL objects
>    which depend on it.

Starting with the DSO itself is what you select with DF_SYMBOLIC.  It's
generally a very bad idea.  Which other scopes are searched depends
heavily on the actual situation.  There won't be any "this is how C++
needs it and therefore this is how it's gonna be".


I'll look at all this hopefully in two weeks from now.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20020530/f2acd07b/attachment.sig>