Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

Nicolas Chauvet wrote: 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. There are many such issues all the time. The usual result is a crash, and a particularly hard to debug one at that. 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