[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: dynamic symbol resolving preference (was: SHA384_Update symbol clash with libgs)
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.
Main Index |
Thread Index |