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