gperftools: split output

[matko]

Description of changes

This PR splits the output of gperftools, to allow applications that link to tcmalloc (provided by gperftools) to not also depend on the profiling tools, which would pull in perl. Additionally, the minimal dynamic tcmalloc library (libtcmalloc_minimal.so on linux) is moved into its own dedicated output, which further allows dropping libunwind for applications that only need a replacement allocator.

Additionally, static libraries get moved to a special output 'static' which goes last on the propagated build output list, ensuring that dynamic linking dependents can drop the static libraries too, and naive linking using the cc wrappers and NIX_LDFLAGS will prioritize dynamic over static linking.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[tobim]

Nothing against this, but wouldn't packaging https://github.com/google/tcmalloc/blob/master/docs/gperftools.md also be a good alternative?

[matko]

Maybe that is possible too. I don't really know the extent of the differences between these two versions though, and I worry that replacing the version of tcmalloc with the slightly different google version may lead to surprises down the line (such as errors that only seem to happen on Nix but which can't be reproduced on dev machines running something else).

For what it's worth, getting tcmalloc_minimal on Debian would get you the version from gperftools. It looks like the same goes for Fedora. I think it's therefore reasonable to assume that most (non-google) packages depending on tcmalloc would be expecting to get it from gperftools.

[matko]

Giving this PR a nudge since it has been here for about 2 weeks.

@vcunat could you have a look?

[nixos-discourse]

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

https://discourse.nixos.org/t/prs-already-reviewed/2617/1953

[phanirithvij]

should this target staging?

[matko]

Should it? I'm new to this so I'm not very familiar yet with the nixpkgs development process. I also had no idea that this would affect so many packages when I made the PR.
Please let me know if I need to change anything or reopen this PR to target another branch.

[phanirithvij]

Read
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#staging
And this most importantly
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#something-went-wrong-and-a-lot-of-people-were-pinged
https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging

I can't help much since I've never rebased myself.

Or a new PR targeting staging should be fine.

[matko]

Repushed to resolve conflict with tree-wide change.

[matko]

Another two months passed and a new version of NixOS was released in the meantime. is there any chance of this getting merged or should I just close?

[tobim]

I'd like to see this merged, but I can't do that myself.

[matko]

This will need another fixup since gperftools got moved into the by-name hierarchy. I'm not sure if it makes sense to keep doing this here or to open a new PR though.
And the whole thing is pointless if nobody is going to merge it anyway.

[phanirithvij]

And the whole thing is pointless if nobody is going to merge it anyway.

You can post it on discourse "prs ready for review" and matrix #review-requests channels. And reach out to @vcunat on matrix or discourse for a review request.
It is not pointless, please don't think that way, everyone with a commit access is a volunteer and I'm sure you already know that.

I'm not sure if it makes sense to keep doing this here or to open a new PR though.

You can do it in this pr.

Just a headsup.

There is a treewide nixfmt pr which will conflict with this soon https://discourse.nixos.org/t/nix-formatting-team-treewide-nixpkgs-formatting/56666 as it is touching by-name/gperftools/package.nix as well. It will get merged on Dec 11 (mentioned in the discourse post)
So you might have to fix conflicts again or you can adapt it right now.

And I am not a commiter, just came across your pr.