autoPatchelfHook: add keep_libc flag

[squalus]

Description of changes

• Add keep_libc flag to disable the default libc handling. Intended to be used by systemd.
• Add autoPatchelfFlags to autoPatchelfHook for passing arguments to the autoPatchelf script

This reverts part of the change made in #307068 / 80be926.

Fixes #332533

Relevant: #325126

cc @ElvishJerricco @layus

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.

[ElvishJerricco]

This will break systemd initrd, which relies on leaving glibc in the rpath of binaries that had it before the autoPatchelfHook (actually, I think it also breaks scripted initrd).

[squalus]

Updated to accommodate systemd's requirement for different libc handling.

[squalus]

Fixes #333710

[ElvishJerricco]

Other than updating the comment, this looks good to me. I think we can take it out of draft and once the comment is updated we can merge.

[ElvishJerricco]

Can you add to the comment above to include this condition?

[squalus]

Added some new comments and adjusted the flag description. I tried to make it easier to understand. Feel free to suggest new language if anything comes to mind.

[ElvishJerricco]

@squalus Well, originally, that comment was written to have one numbered bullet point for each of the conditions; the idea being to explain step by step what the loop is doing. So I would have preferred adding another bullet point and clarifying why each of the two libc steps is where it is in the process. Maybe something more like this?

            # 1. If a candidate is an absolute path, it is already a
            #    valid dependency if that path exists, and nothing needs
            #    to be done. It should be an error if that path does not exist.
            # 2. If a candidate is found within libc, it should be dropped
            #    and resolved automatically by the dynamic linker, unless
            #    keep_libc is enabled.
            # 3. If a candidate is found in our library dependencies, that
            #    dependency should be added to rpath.
            # 4. If all of the above fail, libc dependencies should still be
            #    considered found. This is in contrast to step 2, because
            #    enabling keep_libc should allow libc to be found in step 3
            #    if possible to preserve its presence in rpath.

I dunno. Your call. Whatever you're most happy with is good with me. Just wanted to offer an explanation for why the bullet points were listed that way.

[squalus]

@ElvishJerricco Updated to use your suggested language. I think that's more clear. Much appreciated.

[ElvishJerricco]

Thanks @squalus! I did a squash merge just to get those comment tweaks all into the one commit.