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).
the (vc4 redox) flex conditional was missing in all other gcc version
because gcc6 was the default at the time it was added
that is one of the problems common/dependencies.nix fixes
This reverts commit 2c931bd5f4.
The https://github.com/NixOS/nixpkgs/pull/209153 reverted --sysroot=/
change as it broke other astects of library search paths.
While it might still be useful to pull in gcc libraries when
non-standard --sysroot= is passed there are no meaningful use cases of
it in `nixpkgs` yet. Let's revert it for now.
On a native (host==build==target) build, `${with_build_sysroot}` can
be omitted. In that case, the line modified by this commit is
correct.
However, if `--with-build-sysroot=` is passed to `./configure`, then
`${with_build_sysroot}` will be used, similar to the cross case, and
the headers will be taken from:
${with_build_sysroot}${native_system_header_dir}
See:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=62bc908b991ff0b700225aef32743cd3d7c4daaf;hb=HEAD#l2439
This commit adjusts the comment to account for the case where
`--with-build-sysroot` is passed to a native compiler.
With all libcs I'm aware of, libdl is now either empty (Glibc, musl,
uclibc, illumos), a symlink to libc or equivalent (Apple), or does not
exist (FreeBSD, NetBSD). So explicitly linking libdl now does nothing
for the former platforms, and breaks the build for the latter
platforms.
With this patch I've removed -ldl from all overridden linker flags for
all free packages in Nixpkgs. Everything still seems to build.
I'm reasonably confident this is no longer necessary, as uclibc's
libdl.a is empty, and I can cross-build stdenv.cc.cc for
x86_64-unknown-linux-uclibc with libgomp enabled.
LLVM does not provide a drop-in replacement for as(1).
This makes it possible to build a GNU Fortran cross compiler from GNU
to LLVM — e.g. buildPackages.gfortran for
{ system = "aarch64-linux"; useLLVM = true; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80431
This bug annoys me because I hit it when working on Nix. It causes
miscompilations in such a way that I am hard-pressed to think how a
program could inadvertainly rely on the bug (such that it would be
broken by the fix).
The bug is longstanding, and the (quite small) applies without
modification to many older GCCs. I have confirmed by running the test in
that commit that does indeed fix the bug with the backports too.
I would like to use --sysroot=/nix/store/does/not/exist hack
for both `gcc` and `clang` drivers to remove default include
(and library) search paths when we override them with libc.
For `gcc` it works as is. But for `clang` it also drops some of
`gcc` search paths`. Let'sconsider 2 lookups.
Successful lookup (no `--sysroot`):
$ printf "int main(){}" | clang++ -x c++ - -Wl,--verbose |& grep -F stdc++
attempt to open /nix/store/...-gcc-11.3.0/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/libstdc++.so failed
attempt to open /nix/store/...-gcc-11.3.0-lib/x86_64-unknown-linux-gnu/lib/libstdc++.so failed
attempt to open /nix/store/...-clang-11.1.0-lib/lib/libstdc++.so failed
attempt to open /nix/store/...-gcc-11.3.0/lib64/gcc/x86_64-unknown-linux-gnu/11.3.0/libstdc++.so failed
attempt to open /nix/store/...-gcc-11.3.0/lib64/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../lib64/libstdc++.so failed
/nix/store/...-gcc-11.3.0/lib64/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../../lib64/libstdc++.a
Failed lookup (has `--sysroot`):
$ printf "int main(){}" | clang++ --sysroot=/does/not/exist -x c++ - -Wl,--verbose |& grep -F stdc++
attempt to open /nix/store/...-gcc-11.3.0/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/libstdc++.so failed
attempt to open /nix/store/...-gcc-11.3.0-lib/x86_64-unknown-linux-gnu/lib/libstdc++.so failed
attempt to open /nix/store/...-clang-11.1.0-lib/lib/libstdc++.so failed
attempt to open /nix/store/...-gcc-11.3.0/lib64/gcc/x86_64-unknown-linux-gnu/11.3.0/libstdc++.so failed
/nix/store/...-binutils-2.39/bin/ld: cannot find -lstdc++: No such file or directory
Note how `clang` starts the search roughly from
`gcc-11.3.0-lib/x86_64-unknown-linux-gnu/lib` in both cases. I think
it's our preferred location for both native and cross cases.
The change adds such a symlink:
`gcc-11.3.0-lib` -> `gcc-11.3.0-lib/x86_64-unknown-linux-gnu`
