bcc: remove refs to LLVM static libs that bloated closure

[LunNova]

Reduces closure from ~1.7G to ~300M

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.
• Follows the automation/AI policy.

[LunNova]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 562660
Commit: bfe0e82aa5eb7ead34b81cf7136e2ad62834eecf

---

x86_64-linux

✅ 10 packages built:

• bcc (linuxKernel.packages.linux_5_10.bcc, linuxKernel.packages.linux_5_15.bcc, linuxKernel.packages.linux_6_1.bcc, linuxKernel.packages.linux_6_12.bcc, linuxKernel.packages.linux_6_18.bcc, linuxKernel.packages.linux_6_6.bcc, linuxKernel.packages.linux_7_2.bcc, linuxKernel.packages.linux_xanmod.bcc, linuxKernel.packages.linux_xanmod_latest.bcc, linuxKernel.packages.linux_xanmod_stable.bcc, linuxKernel.packages.linux_zen.bcc, linuxPackages.bcc, linuxPackages_latest.bcc, linuxPackages_xanmod.bcc, linuxPackages_xanmod_latest.bcc, linuxPackages_xanmod_stable.bcc, linuxPackages_zen.bcc, python314Packages.bcc)
• bpftrace (linuxKernel.packages.linux_5_10.bpftrace, linuxKernel.packages.linux_5_15.bpftrace, linuxKernel.packages.linux_6_1.bpftrace, linuxKernel.packages.linux_6_12.bpftrace, linuxKernel.packages.linux_6_18.bpftrace, linuxKernel.packages.linux_6_6.bpftrace, linuxKernel.packages.linux_7_2.bpftrace, linuxKernel.packages.linux_xanmod.bpftrace, linuxKernel.packages.linux_xanmod_latest.bpftrace, linuxKernel.packages.linux_xanmod_stable.bpftrace, linuxKernel.packages.linux_zen.bpftrace, linuxPackages.bpftrace, linuxPackages_latest.bpftrace, linuxPackages_xanmod.bpftrace, linuxPackages_xanmod_latest.bpftrace, linuxPackages_xanmod_stable.bpftrace, linuxPackages_zen.bpftrace)
• ebpf-usb
• fence
• oci-seccomp-bpf-hook (linuxPackages.oci-seccomp-bpf-hook)
• python313Packages.bcc
• python313Packages.proton-vpn-daemon
• python314Packages.proton-vpn-daemon
• sockdump
• system76-scheduler

[LunNova]

nixosTests.bpf is still happy.

[martinetd]

Oh I see, bcc links with clang/llvm static libraries hmm...

Technically I'd rather go the other way around: keep the large closure but set ENABLE_LLVM_SHARED=ON so the code isn't duplicated, which would save space on systems that pull in clang anyway (albeit much less impressive than your ~1.7G to ~300M (398.8MB locally) -- it only reduces bcc itself from 160M to 18M), but I can see your point and some "production" environments could want bcc without the huge llvm libs...

Would it perhaps make sense to do both? e.g. make bcc shared but add a new bcc-staticllvm subpackage (through an option to the bcc package.nix) that links statically as currently with your remove-references-to added?

Either way if we keep remove-references-to I'd rather add a check that llvm is statically linked (e.g. ldd lib/libbcc.so doesn't list clang) and that llvm/clang derivations don't appear anywhere else in $out as it might creep back in on major upgrades

[LunNova]

I don't want to split into shared/static. Shared would be better, (with pkgsStatic.bcc still being static) but LLVM needs its static libs to live in .dev and not .lib or that leaves us with the large closure size this tries to fix.
Will add disallowedReferences.

[LunNova]

added disallowedReferences

[martinetd]

I don't want to split into shared/static. Shared would be better, (with pkgsStatic.bcc still being static) but LLVM needs its static libs to live in .dev and not .lib or that leaves us with the large closure size this tries to fix.

Right, perhaps llvm closures can be reworked somehow but that does sound like more work...

I think at this point prioritizing this closure size or prioritizing the whole store size with llvm installed is more of a project decision than a maintainer decision, so happy to defer to whoever knows about it -- would you be kind enough to bring it up on discourse or somewhere it can get attention perhaps?

Ideally I'd see something like:

• this patch as a stopgap (it's definitely not worse than what we currently have, so I have no reason to block it)
• fiddle with llvm until everyone's happy
• remove this patch and switch to dynamic linking
  as a way forward, but that implies someone has time to work on llvm, and I sure don't...

(BTW moving the .a out would only reduce the closure size by about 350MB (so 1.7GB -> 1.55GB from dynamic linking bcc -> 1.2GB from not keeping llvm .a around), I'm not sure this is good enough for you)

added disallowedReferences

Thanks

[LunNova]

Sadly I don't have the time to try to rework anything in the LLVM package set at the moment. There's a discussion somewhere in matrix about trying to fix the .a files not to get pulled in for LLVM, not going to try to permalink to it because I can never get matrix search to work.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/7569