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

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

> 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?