I’ve just compiled my own library that installs a .a static library and it went into $out instead of $dev. Is this intentional? I’ve always assumed static libraries are a devel-only artifact.
It’s up to you to set up the outputs of a multi output derivation.
Though as far as I understand, for compatibility with pkgsStatic just having them where the .so would be put is preferable.
2 Likes
IIRC there are some snags which essentially require to have both in the same directory (if both should work). I mean, assumptions which didn’t count on Nix*
e.g. the .pc files only allow you to specify a single libdir= AFAIK. And there might be more. You could certainly find some old discussions about this. I’ve been not been really using static linking (or caring for it significantly).
I personally prefer when a package entirely skips installing the static library unless stdenv.hostPlatform.isStatic is set. Then you don’t have to waste download/disk if you want to use the shared library but still have access to a static library if you need.
You can see this in action in Nixpkgs by, for example, searching for enableStatic ? stdenv.hostPlatform.isStatic.
3 Likes
Yes, this would be correct, however as people say the ecosystem isn’t really prepared for it. You can specify a lib output that will be used for both static and dynamic libraries. I agree that in most cases the best solution is to not include static libraries in packages, although in some cases like LLVM it’s been tempting to patch in support for separate paths.
(Actually, even .so files bundle together executable code only needed at runtime and linker metadata – an area macOS’s .tbd linker stubs improve on.)
2 Likes