[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
dynamic symbol resolving preference (was: SHA384_Update symbol clash with libgs)
> IMO, they're both at fault.
I'm not at all an expert on the field of dynamic linking, but what strikes
me as odd is:
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.
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?
But probably my idea of dynamic linking is too simplistic or there are
real use cases for that situation where one wants the opposite behaviour?
Main Index |
Thread Index |