Bump binutils 2.46.1, gcc 16.1.0, musl 1.2.6, linux 6.19.14

[Itxaka]

Update all bumpable packages to their latest upstream releases and adapt the build to gcc 16's changed defaults.

• binutils 2.45 -> 2.46.1 (b3sum + sha256 updated)
• gcc 15.2.0 -> 16.1.0 (b3sum + sha256 updated)
• musl 1.2.5 -> 1.2.6 (b3sum + sha256 updated)
• linux 6.17.7 -> 6.19.14 (b3sum + sha256 updated)

Drop all four musl upstream patches: they were post-1.2.5 fixes that are now included in the 1.2.6 release.

gmp, mpc, mpfr, isl and pkgconf were already at their latest releases.

New libatomic step (required by gcc 16)

gcc 16 changed its default link spec to inject -latomic_asneeded into every
linked program unless -fno-link-libatomic is passed (visible in
gcc -dumpspecs). Without an installed libatomic/libatomic_asneeded, all
linking fails — even a plain C printf — with:

cannot find -latomic_asneeded

This PR adds a mandatory libatomic build + install step (Step 5.5), right after
libgcc-shared and before the optional libstdc++-v3 step.

Tested and built from a clean tree and link-tested a C and a C++ program with several arches (aarch64, riscv64, armv7 and x86-64), all produced valid target ELF binaries.

A note on how this was produced

Heavy use of AI was made in this patch to investigate the possible problems
(e.g. tracking down the gcc 16 -latomic_asneeded link regression and which
musl patches were superseded by 1.2.6). However, human intervention was done to
verify that the checksums, the produced artifacts, and the builds all execute
correctly.

[Itxaka]

cc @firasuke not sure if wanted or not, let me know about this, cheers!

[firasuke]

Hey there @Itxaka , I appreciate the time and effort that went behind this PR.

The changes regarding the bumping part and the "now" unnecessary patches look good to me.

It is the additional step that was added that is concerning.

Reading gcc 16 release notes it appears that libatomic is now automatically linked "as needed" for arm, and looking at gcc link options it appears that -flink-libatomic is enabled by default.

My understanding is that gcc builds and installs libatomic automatically for supported architectures, rendering the step you suggested excessive as it would install libatomic for all targets regardless of whether they need it or not.

I also do not think it would be a wise thing to do the opposite with --disable-libatomic as that would hurt architectures that do require it (e.g. riscv).

Did you attempt to configure gcc with --disable-libatomic or perhaps attempt not injecting it for architectures that absolutely require libatomic?

Also summoning you @takusuman , if you have time of course, I am interested to hear your thoughts on this.

[firasuke]

My understanding is that gcc builds and installs libatomic automatically for supported architectures, rendering the step you suggested excessive as it would install libatomic for all targets regardless of whether they need it or not.

I also do not think it would be a wise thing to do the opposite with --disable-libatomic as that would hurt architectures that do require it (e.g. riscv).

If linking to libatomic is always enabled, even for architectures where libatomic is not built by default, then wouldn't the easier solution be to pass --enable-libatomic to the main gcc configuration in step 3?

Or perhaps it is being passed by default, but it is being installed selectively for certain architectures and not for others, which is why @Itxaka suggested a standalone step. If that's the case then I wouldn't mind having libatomic as an additional make/make install target, it would make sense to place it alongside gcc and it better be before libstdc++-v3. Personally given how mussel fragments the build of gcc, it would make sense to have the libatomic target install alongside libgcc-shared since it would always be installed.

So rather than having a separate sub-step (5.5), it would be better to merge it into step 5, so that it becomes cross-gcc (libgcc-shared and libatomic) and that respective README and documentation sections be updated to reflect this change.

If (and for whatever reason) libatomic required libgcc (shared) be built and installed beforehand (my understanding is that libgcc (static) / libgcc.a should be enough), then changes made by @Itxaka look good to me provided that they consider it a separate step (6) and bump the other numbers and update respective README and documentation sections. Bonus points if the building of libatomic was toggled using an optional flag that was enabled by default.

[Itxaka]

@firasuke I have no idea to be honest so no opinion to have here, musl cross building is kind of out of my element, hence my use of AI to guide me doing this.

If you think this is the proper way of doing It I can do it no problem :D

So rather than having a separate sub-step (5.5), it would be better to merge it into step 5, so that it becomes cross-gcc (libgcc-shared and libatomic) and that respective README and documentation sections be updated to reflect this change.

If (and for whatever reason) libatomic required libgcc (shared) be built and installed beforehand (my understanding is that libgcc (static) / libgcc.a should be enough), then changes made by @Itxaka look good to me provided that they consider it a separate step (6) and bump the other numbers and update respective README and documentation sections. Bonus points if the building of libatomic was toggled using an optional flag that was enabled by default.

[firasuke]

Looks good to me, merged!