glibc: 2.35-224 -> 2.37-8

[Ma27]

Description of changes

Note: very early draft, but opening it to track the work and to avoid potentially duplicated efforts.
cc @lovesegfault @vcunat

Also, can anybody create a Hydra jobset for me, please?

Announcements:
https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html
https://sourceware.org/pipermail/libc-alpha/2023-February/145190.html

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/)
• 22.11 Release Notes (or backporting 22.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[vcunat]

Jobset: https://hydra.nixos.org/jobset/nixpkgs/pr-188492-glibc-2.36
(but it looks pretty bad for now)

[Ma27]

(but it looks pretty bad for now)

I mean where's the fun if everything would've built fine already 🙃

But to be serious: I didn't expect it to fail that early, but the problem appears to be GCC: https://hydra.nixos.org/build/189053872/nixlog/1/tail
I'll take a look soonish. But I mean given that it breaks so much so early, creating a jobset for this change was appropriate %)

[zhaofengli]

Also we might want to consider applying the patch to re-enable DT_DASH in the glibc .so like what Arch does. If we decide to do so, we should re-evaluate by the time 23.05 comes.

• GLIBC update broke EAC for most games that use it ValveSoftware/Proton#6051
• https://blog.hiler.eu/win32-the-only-stable-abi

[Ma27]

@vcunat so I just fixed a few more failing builds, updated glibc to the latest rev from 2.36 and pulled in latest upstream/staging. Let's see what the next Hydra evaluation says, but it seems quite good IMHO.

Do you think it makes sense to add aarch64-linux as second system to see if we're missing something obvious there?

[vcunat]

Yes why not, added. (that also triggered evaluation)

[vcunat]

So, glibc 2.36 missed NixOS 22.11, right? #194208 (comment)

[Ma27]

Yep, but I didn't have the energy last week to finish this anyways 🤷

[Ma27]

Rebased another time, rustc on arm should be fixed again, let's see how much is actually broken now.

[vcunat]

Cutoff for merge to 23.05 would be in two weeks:
#223562

It's not day-precise in practice, but most likely better merge sooner than later (if for 23.05). Low-rebuild breakages can deferred after merging, unless it's some very important package.

[Ma27]

Can't say much for x86_64-linux-specific breakage (because all of these builds are still hanging in the queue), but aarch64-linux looks quite fine I'd say:

A lot of stuff is transitively broken because of apipkg (but restarting the build appears to solve this, I just didn't want to manually restart every single affected job manually, see https://hydra.nixos.org/build/214454805). Same for moto, i.e. the home-assistant thingies seem to be false-positives as well, see https://hydra.nixos.org/build/214456540 (the cause for dependency failed).

An obvious problem is swift: https://hydra.nixos.org/build/214392116 (error is reproducible on x86_64-linux). I've never used swift, so no idea about that, but I'd say that swift isn't a sufficiently large subsystem to block on that, IMHO the swift maintainers should figure out a solution during zhf (but I'll give them a heads-up now, cc @stephank @Trundle @dduan @trepetti @dtzWill ).

So unless I missed something obvious, there don't seem to be any significant regressions, the last one - which is already fixed - is the QEMU build error.

For me this is enough to undraft this, but I'll leave it up to you to merge (perhaps we should at least await the x86_64-linux part first).

[vcunat]

I restarted all failed, as aarch64-linux machines tend to have extra free time lately.

[vcunat]

Sounds good enough for staging. I rechecked that stdenv still builds on the merge result, as stdenv bootstrapping changed noticeably in the meantime.

[vcunat]

Thanks.

[stephank]

An obvious problem is swift: https://hydra.nixos.org/build/214392116 (error is reproducible on x86_64-linux). I've never used swift, so no idea about that, but I'd say that swift isn't a sufficiently large subsystem to block on that, IMHO the swift maintainers should figure out a solution during zhf (but I'll give them a heads-up now, cc @stephank @Trundle @dduan @trepetti @dtzWill ).

The error there is a simple JSON parse error, which is caused by the extra warning output. I'm not yet sure where that direct reference to protected function output is coming from, though. That's not coming from glibc either, is it?

[vcunat]

TSCUtility/Triple.swift:209: Fatal error: Failed to parse target info (malformed).

FYI, this regression will most likely very soon get to master+unstable (and 23.05).

[stephank]

FYI, this regression will most likely very soon get to master+unstable (and 23.05).

It's unfortunate, but I don't have the bandwidth to investigate this right now. What time I find is spent on the Swift 5.8 upgrade. Hopefully that magically fixes it, but probably not. Maybe we can do a 23.05 backport later when we have a fix, but until then we'll have a broken Swift on Linux unless someone else can take a look. I agree it's not a blocker.

[stephank]

#225197 fixes the Linux build of Swift. I did not find a direct cause, but found issues with CMake >=3.25 in general, so suspect that's what fixed it. (I created an upstream PR. They use an older version of CMake in CI, so didn't notice.)