Copies of shared libraries instead of symlinks in the store and docker

I see that instead of symlinking shared libraries are copied in the Nix store. For instance:

 ls -ilh /nix/store/j9bsib85kmxrv67w7xwyq9pjnv0cfgr4-mkl-2021.1.1.52/lib/libmkl_sycl.*
34489078 -r-xr-xr-x 1 root root 617M Dec 31  1969 /nix/store/j9bsib85kmxrv67w7xwyq9pjnv0cfgr4-mkl-2021.1.1.52/lib/libmkl_sycl.so
34489079 -r-xr-xr-x 1 root root 617M Dec 31  1969 /nix/store/j9bsib85kmxrv67w7xwyq9pjnv0cfgr4-mkl-2021.1.1.52/lib/libmkl_sycl.so.1

Is that expected? Are symlinks for shared libraries not used at all? Is nix optimise-store the proper way to turn them all to hard links? If the hard links are what I should be using, how to use them in Docker images created with the dockerTools?

That looks like a packaging oversite to me. Those should be symlinks.

1 Like

@Sandro Thanks! So these lines seem to be the culprit https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c6b212a18bdf2433e71/pkgs/development/libraries/science/math/mkl/default.nix#L134

The code uses the install utility. What is the proper nixpkgs design pattern for this? Just cp -a? I’ll fix and submit a PR.

Yes, cp should be good enough. install is apparently resolving symlinks.

Urgh. For a tool made for that exact purpose, install has stupid defaults and lacks configuration options.

Please also add a comment why cp is necessary in that instance.

1 Like

I’ve kinda wondered if it would make sense (in terms of speed, accuracy, legibility, maintainability, etc.) to have some sort of ~declarative filesystem-operations tool with a DSL for describing what goes where, what states should be errors, what the permissions should be, etc., with the tool applying the rules in a single invocation.

1 Like

https://github.com/NixOS/nixpkgs/pull/189142

2 Likes