@GrahamcOfBorg build libseccomp.lib libseccomp

cc @thoughtpolice

@jtojnar @danieldk please leave a comment explaining your thumbs-down reaction. Sascha has taken the effort to improve Nixpkgs, so the least you could do is explain in a few words why this might not be the right solution. Thank you.

Sorry, was busy at the time. Most of systems will not need static builds so always including them will bloat the closures there.

For that reason, we usually add false-by-default enableStatic argument that is then enabled in https://github.com/NixOS/nixpkgs/blob/7ebcaec02f2f250220db63ffc87d69663ffdaa86/pkgs/top-level/static.nix

@jtojnar @danieldk please leave a comment explaining your thumbs-down reaction. Sascha has taken the effort to improve Nixpkgs, so the least you could do is explain in a few words why this might not be the right solution. Thank you.

My apologies @saschagrunert , I didn't intend to be rude.

I have encountered some cases before where Nix derivations were installing static libraries, leading to other derivations linking to the static library rather than the dynamic library (the most recent case I encountered was sortmerna linking statically against rocksdb). When static libraries are not installed by default, it makes it much easier to detect or avoid such cases.

To me, our default (outside some language ecosystems such as Rust and Go) is dynamic linking and dontDisableStatic is provided as an escape hatch that people can use to enable building of static libraries. This will become confusing if certain derivations have the opposite behavior.

Of course, there may be some specific use case for libseccomp that I missed.

Sorry again @saschagrunert , you contributions are very much appreciated 👍 .

Thank you for the clarification @danieldk! 🙏 I'm happy to close this PR for now. In terms of libseccomp it seems confusing that many (most?) distributions package the static library together with the dynamic one, so I thought this pattern might apply well to libseccomp, too. 🤷