This is more than a little strange.
I have a docker image I’ve built, with a nix installation on it (2.24.9).
I have downloaded the 24.05 nixpackage info tarball and unpacked it locally, and everything works fine when I log in to the Docker image and invoke Nix-shell.
E.g. docker# /root/.nix-profile/bin/nix-shell /tmp/myconfig.nix uses the installed nix-store it created when I built the Docker image, and it’s all happy.
But now, I’m using that docker image in a Jenkins Kubernetes pipeline, and when I have one of the stages invoke that line exactly (inside the aforementioned Docker container), I get a REALLY confusing error message:
/root/.nix-profile/bin/nix-shell: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
libcrypto.so.1.0.0 is a REALLY old library (it’s 3.x now) and I have no idea where any binary might be using that. It’s not anything I’m loading into nix itself via the config file, it has to be something internal to nix-shell. The /tmp/myconfig.nix file contains virtually nothing:
let
nixpkgs = /opt/nix/nixpkgs/24.05;
pkgs = import nixpkgs {};
in
pkgs.mkShell {
packages = with pkgs; [
SDL
];
}
Again, this works just fine when I run docker on my local system. I can’t imaging Kubernetes is doing anything different - it’s running the exact same image, and the invocation of nix-shell is identical on it.
What the heck is looking for libcrypto.so.1 inside nix-shell (even an LDD of nix-shell shows it doesn’t want libcrypto.so.1.0.0 - it wants, and finds, libcrypto.so.3 )