I use at least two binary applications, which are built on Debian: Guitar Pro and Spotify. Both depend on specific symbols in libcrypto: /usr/lib32/libcrypto.so.0.9.8: version `OPENSSL_0.9.8' not found This issue is present for a long time, c.f.: https://forums.gentoo.org/viewtopic-t-835256-start-0.html http://rt.openssl.org/Ticket/Display.html?id=1222&user=guest&pass=guest Thus, I dug into the openssl package building of debian and found a patch they apply to every openssl build. They add a version script patch, which basically adds a file and changes the configure script. The patch works fine for me for openssl:0.9.8 and openssl:0. So far, I worked around the issue by dropping precompiled openssl libraries into the application folders. But that's bad due to the lack of automatic updates. It would be great to apply the patch, too, since Debian/Ubuntu is the de-facto standard for proprietary software. Reproducible: Always
Created attachment 401848 [details, diff] for openssl-0.9.8 patch from debian's openssl source package (debian/patches/version-script.patch)
Created attachment 401850 [details, diff] for >=openssl-1.0
Adding symbols to a library should be done by upstream, not individual distros. Otherwise we run into pointless cross-distro incompatibility, both for binaries as you describe and from developers making incorrect assumptions from running tests on systems with heavy distro-level modifications. If debian ships a custom-patched and incompatible openssl build, the solution is not for other distros to follow their poor example. In stead, I suggest: a) Ask debian to stop it. This usually does not work, and in this case that would break binary compatibility there. b) Ask openssl upstream to provide versioned symbols. From the bug you linked it looks like someone did a while back and they are uninterested. c) Ask whoever is providing your troublesome binaries to either not link against openssl (good) or to bundle every library they link to that could potentially be linked against openssl.(less good)
I fully agree that things like this should be upstream. But since they are not interested and many proprietary software is built on Ubuntu nowadays, it would make sense to ship symbols - or at least to provide a way to use the binaries: It seems to be possible to "work around" the issue by *forcing* the bfd linker for openssl. As suggested in bug #545670 the app starts when building with LDFLAGS+="-fuse-ld=bfd". This doesn't add the symbols, but at least makes missing symbols *somehow* not fatal. This is what other distributions like ArchLinux do: $ spotify /opt/spotify/spotify-client/spotify: /usr/lib64/libcrypto.so.1.0.0: no version information available (required by /opt/spotify/spotify-client/spotify) /opt/spotify/spotify-client/spotify: /usr/lib64/libssl.so.1.0.0: no version information available (required by /opt/spotify/spotify-client/spotify) Thus, I suggest to add "-fuse-ld=bfd" to LDFLAGS in openssl ebuils by default, or at least add a warning about the consequences when using the gold linker when building openssl.
This issue came up in bug 545670
eroen covered things nicely in comment #3
