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`
The code was intended to use something like
[ $buildConfig == *linux* ]
but never did and use always-false
[ buildConfig == *linux* ]
As it's in nixpkgs for a few years let's just delete it instead of
restoring.
