The stable release has too many AArch64 issues, but they seem to
have been fixed upstream; Arch is shipping a Git snapshot. The next
stable release should be out by the time 25.05 is finishing up,
so this should be okay as a temporary solution.
This is the GCC 14-20241116 snapshot. We use that identifier as our
package version, diverging from our usual unstable version convention,
because it identifies itself as “gcc (GCC) 14.2.1 20241116” and
comes in `gcc-14-20241116.tar.xz`; 20241116 is therefore a useful
version identifier to use verbatim, and 14.2.0-unstable-2024-11-16
would potentially be confusing for a version that calls itself
14.2.1. The next stable release from the GCC 14 branch will be 14.3.0,
so there should be no ambiguity here.
Getting this version is a little complicated; we need the precompiled
`flex(1)` output that these Git snapshots don’t include. Thankfully,
the source file hasn’t changed since 14.2.0, so we can simply
download 14.2.0 too and extract the precompiled file. A little
merging finesse is required for the `aarch64-darwin` patch, which we
also upgrade.
The GCC bootstrap builds each stage with an unwrapped GCC, which needs
to correctly handle looking for libraries and headers in sysroot.
Setting the native header folder to `/usr/include` will actually cause
GCC to search `<sysroot>/usr/include`, which is the SDKROOT in nixpkgs.
The original logic was prepending to the array, but this one prepends
the array to itself, which breaks the x86_64-linux stdenv bootstrap. The
correct thing to do is build up the arguments in a temporary array and
prepend it like the original code was doing.
https://github.com/NixOS/nixpkgs/pull/328380 updated `gcc11` from
`11.4.0` to `11.5.0` but the darwin patch was not ready then. Let's
update it in hopes that it fixed `darwin` build.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
Fixes
/nix/store/8pq96x5qsczrmc926795lf7j4dzy2c8q-binutils-patchelfed-ld-2.43.1/bin/ld: ../../src/liblzma/.libs/liblzma.so: undefined reference to `__pthread_cond_timedwait64'
collect2: error: ld returned 1 exit status
while building `xz` for `stdenv`. The root cause is that glibc replaced
`__USE_TIME_BITS64` with `__USE_TIME64_REDIRECTS`[1]. However, the
stage3 GCC seems to use the bootstrap headers from glibc for
`fixincludes`, i.e. headers w/o this change. Because of that, the xz
build with stage3 stdenv gets a header that looks like this:
# ifndef __USE_TIME_BITS64
/* ... */
# else
# ifdef __REDIRECT
/* ... */
# else
# define pthread_cond_timedwait __pthread_cond_timedwait64
# endif
# endif
Since __USE_TIME_BITS64 doesn't exist anymore because a new glibc is used
for building, the preprocessor ends up in the condition defining
`__pthread_cond_timedwait64` even though it's not supposed to end up
there since __pthread_cond_timedwait64 doesn't exist on x86_64[2].
I decided to just kill the header here since GCC claims that all the
`pthread.h` only very old glibc versions or platform-specific libcs we
don't use[3].
[1] https://sourceware.org/git/?p=glibc.git%3Ba%3Dcommit%3Bh%3Ddd535f4f19ef2b5c367a362af445ecadcf45401e
[2] https://inbox.sourceware.org/libc-stable/50c0269d-b73c-4e8a-9816-65f72d6082c0@linaro.org/
[3] https://github.com/gcc-mirror/gcc/blob/releases/gcc-14.2.0/fixincludes/inclhack.def
gcc-4.9.4 was released in Aug 3, 2016, 8 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
gcc-4.8.5 was released in June 23, 2015, 9 years ago. It's a branch that
went out of support years ago. Numerous bugs never get backported to
this version.
Let's remove it.
The version of `AvailabilityInternal.h` used in newer SDKs does not work with older versions of GCC that do not support `__has_builtin`. Apply a fixinclude on those versions to allow them to build against the newer version of that header (also used in the source-based SDK after the ld64 update).
Darwin uses absolute path install names, so setting rpaths is unnecessary. This fixes breakage on older versions of GCC that try to set a deployment target that does not support rpaths.
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.
Fix#53753.
Information on llvm version support gleaned from
6609892a2d68e07da3e5092507a730
Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
