Use IEEE-standard floating point on `powerpc64le` instead of
IBM-proprietary formats. The GCC wiki has more details on the history
here:
https://gcc.gnu.org/wiki/Ieee128PowerPC
Nixpkgs' stdenv has no legacy `powerpc64le` installs to deal with
(stdenv did not bootstrap on powerpc64le until very recenty), so it's
much easier decision for us.
Red Hat (i.e. IBM) has tried to do this in each of the last *six*
releases:
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
they and finally shipped it in May with Fedora 36:
https://bugzilla.redhat.com/show_bug.cgi?id=1649936
Apparently glibc 2.35 fixes the last blocker.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This commit adds a derivation `gcc-stageCompare` to
`pkgs/test/stdenv/default.nix`.
It is important to always build this derivation whenever building
`stdenv`! Because we are using a Nix-driven bootstrap instead of
gcc's built-in `--enable-bootstrap`, the `gcc` derivation no longer
performs the post-self-compilation sanity check. You must build
this derivation in order to perform that sanity check.
The major benefit of this new approach is that the sanity check
(which involves a third compilation of gcc) can be performed
*concurrently* with all packages that depend on `stdenv`, rather
than serially. Since `stdenv` has very little derivation-level
parallelism it cannot take advantage of more than one or perhaps two
builders. If you have three or more builders this commit will
reduce the time-to-rebuild-stdenv by around 20% (one of three gcc
rebuilds is removed from the critical path, and stdenv's build time
is dominated by roughly 3*gcc + 1*binutils + 1*bison-test-suite).
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This commit adds `gcc/common/checksum.nix`, which contains code
common to both gcc11 and gcc12, implementing the `enableChecksum`
feature.
When gcc's built-in bootstrap (`--enable-bootstrap`) is used, gcc
compiles itself three times and compares a hash of the unlinked `.o`
files from the second and third compilation. The
`enableChecksum=true` parameter performs the same comparison as part
of the `postInstall` phase.
Notably, `enableChecksum=true` can be used with `enableBootstrap=false`.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This commit has no effect on eval. It simply reorganizes the
`gcc11` and `gcc12` expressions so they apply a list of
`overrideAttrs`. The list is currently empty.
Previously, builds such as `cmake` would fail with errors like this:
In file included from /nix/store/injyphmxqgi028skp28fsmdvbdb57nvl-glibc-2.36-48-dev/include/linux/fs.h:19,
from /build/cmake-3.24.2/Utilities/cmlibarchive/libarchive/archive_read_disk_posix.c:56:
/nix/store/injyphmxqgi028skp28fsmdvbdb57nvl-glibc-2.36-48-dev/include/linux/mount.h:95:6: error: redeclaration of 'enum fsconfig_command'
95 | enum fsconfig_command {
| ^~~~~~~~~~~~~~~~
The reason behind that is that the kernel exports `linux/mount.h` via
kernel headers APIs that are also defined in `sys/mount.h` from glibc.
To avoid clashes, safeguards were implemented in glibc to prevent this
from happening[1][2].
However, these `#ifndef`-safeguards are removed by `fixincludes` during
gcc's build and the (broken) result is subsequently copied into
`include-fixed/sys/mount.h` which is added to each build via the
cc-wrapper. To work around this, I decided to simply drop the file: it
also exists in glibc's output and our gcc12 doesn't seem to expose this
anymore anyways.
[1] Commit bb1e8b0ca99b5cbedfae3e6245528a87d95ff3e2
[2] Commit 3bd3c612e98a53ce60ed972f5cd2b90628b3cba5
This commit updates the `buildFlags`, which is a single string with
one of four possibilities:
- ""
- "profiled"
- "bootstrap"
- "profiledbootstrap"
Previously only the last two were possible. Since
2ea3482502 all four are possible.
In 6812dd98c4 I mistakenly had the
implication order reversed. This commit corrects that mistake.
The original assertion (which is correct) was the following, which
asserts that if you enable the GDB plugin, you must enable plugins
generally (there is shared infrastructure):
```
assert enableGdbPlugin -> enablePlugin;
```
When the option name was changed to `disableGdbPlugin`, I
incorrectly wrote:
```
assert disableGdbPlugin -> enablePlugin;
```
And then again incorrectly wrote:
```
assert disableGdbPlugin -> !enablePlugin;
```
This commit uses the correct equivalent for the first statement,
which is the contrapositive:
```
assert !enablePlugin -> disableGdbPlugin;
```
This commit adds an option `disableGdbPlugin` which controls whether
or not the plugin *for* GDB will be built. This plugin contains a
copy of `gcc`.
The configure flag that this option controls is called
`--disable-libcc1`. This flag name is slightly confusing: it is
used only by GDB (and apparently unmaintained), yet the flag name
does not mention GDB. This is why the option name is different from
the configure flag name.
The primary motivation for this commit is to allow the following PR
(which is not yet merged) to pass `--disable-libcc1` when building
the final native (build=host=target) compiler as part of the stdenv
bootstrap:
https://github.com/NixOS/nixpkgs/pull/209870
We need to `--disable-libcc1` in this scenario because gcc's build
machinery links `libcc1` against the `libstdc++` that is part of the
*compiler used to compile gcc*, rather than against the `libstdc++`
that is built *by* gcc. In an FHS distribution this distinction is
not terribly important because dynamically linked libraries are
late-bound (ld.so resolution). However in nixpkgs this causes a
reference back to the bootstrapFiles to leak all the way through to
the final stdenv.
More details can be found in the comment in
`pkgs/stdenv/linux/default.nix` of the PR linked above.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Our openjdk derivations fail to build with `-march=opteron` (via
either `NIX_CFLAGS_COMPILE` or `hostPlatform.gcc.arch`). This was
fixed upstream in gcc12 but not carried back to gcc11:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d243f4009d8071b734df16cd70f4c5d09a373769https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910
Since gcc11 is still nixpkgs' primary compiler, this PR cherry-picks
the fix out of gcc12.
Unfortunately since `-march=` can be added after the `gcc11`
derivation is built we can't apply this patch conditionally (which
we don't usually do anyways).