Nicolas Chauvet wrote: > This could be true before the "gold" linker, I expect it tend to > disappear since we explicitly link a given library. I don't think > preload would mix symbols in this case.
The checks that got added are only link-time checks. The runtime ld.so still works the same way as always, a symbol is global and the linker will just randomly pick the first symbol it finds with the given name in ANY loaded library. > Do you have any reference of such issue in the recent history ? There are many such issues all the time. The usual result is a crash, and a particularly hard to debug one at that. > There are already several libraries (compat or for another ABI) that > are provided multiple times from the repository. They all have the same limitation (except in a few cases where upstream renamed ALL the symbols of the library exactly to prevent that): They CANNOT be directly or indirectly linked into one and the same executable. E.g. it is NOT possible to use anything GTK+ 2 in a GTK+ 3 application. Where this restriction was disobeyed, compatibility libraries HAVE lead to symbol conflicts, e.g. this has been a problem very recently with Berkeley db. (Unfortunately, I don't have the bug ID handy.) This is also one of the reasons why compatibility libraries are discouraged in Fedora and only to be used as a last resort, if porting the applications is impossible in a reasonable timeframe. We also had symbol conflicts without any compatibility library involved, where 2 unrelated libraries (or a library and an executable) happened to use the same public symbol name (often due to not using ELF hidden visibility: hidden symbols are local to the library or executable, visible symbols are global, so if you don't hide your internal symbols, that often exposes symbols with very generic names). But most often it happens with compatibility libraries. So I stand by it: The only practical way to ship an openssl-freeworld is such that it overrides the Fedora openssl. Kevin Kofler