fortify-headers: 1.1alpine1 -> 1.1alpine3

[risicle]

Description of changes

The relevant changes in this bump are the addition of some patches fixing behaviour with clang. I think we're still going to have to patch fortify-headers further to make it more easily disable-able for clang (if not just disable it entirely for clang) but this is a start.

Have built a lot of pkgsMusl packages on nixos x86_64 with this.

cc @NixOS/static

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.11 Release Notes (or backporting 23.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.

[risicle]

On second thoughts this probably isn't urgent enough to go to staging-next.

[yu-re-ka]

Since it doesn't have many (hydra) rebuilds, I think it should go into master.

[risicle]

Well, it's a full rebuild for musl users.

[yu-re-ka]

define "musl users". I have a device that's running full nixos with musl, but that can't be upgraded to current master because of too many build failures being introduced in the last two staging cycles, some of which would be fixed by this.
On the other hand people who do one-off musl package builds probably don't care either.
Generally, I think we care about hydra rebuilds.

[risicle]

Well it's more that I foresee having to add a couple more fixes for this, and it would be better to trigger rebuilds for people once, rather that twice or three times.

Would it be better if we merged #251942 to make this a completely non-urgent problem?

[yu-re-ka]

Would it be better if we merged #251942 to make this a completely non-urgent problem?

Either that or revert #219421 for now and then re-submit it together with other fixes?

[risicle]

#219421 is unrelated. nope that's the one

[yu-re-ka]

which PR introduced the fortify-headers for musl libc then?

[risicle]

No wait, you're right - I've got my numbers mixed up.

[yu-re-ka]

Let's merge this into staging and #251942 into master, and then we're good for now and can figure out how to make it work with clang at some point