Disclaimer: the example is synthetic in order to make it short (so please do not advise how to work around, it is both obvious (as on any non-NixOS) and useless)
I want to support curl --sslv2
to connect some legacy devices.
So I write an overlay:
nixpkgs.overlays = [
(self: super: {
curl = super.curl.override {
openssl = self.openssl.override { enableSSL2 = true; };
};
})
];
Then curl
will be linked against its own openssl
which does support SSL2.
And so libcurl
too.
The programs witch use both libcurl
and openssl
-not-via-libcurl will be linked against two openssl
s.
Which have different paths in nix store but the same names of .so files
Pathes of both openssl
are concatenated in rpath then only one of the openssl
libraries will be loaded (and it is difficult to predict which one, with enableSSL2 = true
or enableSSL2 = false
).
This latest manifestation of DLL hell could be addressed by adding hashes to the names of .so (like in Rust libraries), but it might bring more problems than solve.
So I just left it here to keep track of the problem arised from using “hash only in the path and not in the name” together with Linux concept of “rpath”.
Perhaps someone has a better generic solution than to add hashes to the .so names.