Re: dynamic symbol resolving preference (was: SHA384_Update symbol clash with libgs)

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Apr 06, 2019 at 09:49:22AM +0200, Edgar Fuß wrote:
> 1. The dynamic linker should be able to notice that two libraries are 
> pulled in which export conflicting symbols and warn about it, no? 
> That would have saved me three working days.

No, this is how ELF works - one library can overrifde a publich symbol
(typical example: use your own malloc/free instead of libc's version).

> 2. If a routine inside libssl references a symbol (like SHA384_Update) 
> present in two libraries (libc and libgs) having been pulled into the 
> process, but the file (libssl) containing the reference only depends on 
> one of the two libraries providing the symbol (libc) and not the other 
> (libgs), not even indirectly, it should have a strong preference to 
> resolve the reference to the library being depended on (libc), not some 
> random other one (lbgs) having been loaded, no?

The symbol in lbgs should probably be private.

Martin