We want a `libgcc_s.so` to be built by the first stage
cross-compiler (withoutTargetLibc), since that is the compiler which
will compile the target libc.
This commit accomplishes that, by making three changes:
1. Replacing the `targetPlatform.libc == "msvcrt" &&` conditional
with `enableShared`, so that the code which cross-build
`libgcc_s.so` is used for all cross compilers capable of emitting
shared libraries.
2. Removing the `targetPlatform == hostPlatform` guard from the code
which produces the `libgcc` output.
3. Looking for build products in in "lib/${targetPlatform.config}/"
rather than "lib/", so we will find them when cross compiling.
This commit deduplicates libgcc-related boilerplate which appears in
every version of our gcc expression, by moving it into libgcc.nix.
I will be submitting a separate PR which changes this boilerplate,
but that PR will be much easier to review if I can make the change
in just one place.
Meanwhile, *this* commit has no effect on eval:
$ for A in 10 11 12 13 4.8 4.9 6 7 8 9; do nix-instantiate . -A gcc$(echo $A | tr -d .); done 2>/dev/null | sort | tee before
/nix/store/1a37lnzpnz0dhm3lphiy2gcdrxgqa7ma-gcc-wrapper-4.8.5.drv
/nix/store/5szdivc8il0c3g94dq4wqnq5j77a9h6p-gcc-wrapper-11.4.0.drv
/nix/store/bmmc717wmnp1j2xkd3if5dfxicnflvn5-gcc-wrapper-7.5.0.drv
/nix/store/fc1ggpixv3wqcazchhl2hnn5zl5ds30l-gcc-wrapper-13.1.0.drv
/nix/store/j9c2b20w35r3ag5nxmklhagbwsgjhds2-gcc-wrapper-4.9.4.drv
/nix/store/nq7q57bxmsk2g457wr4b9449as3f216w-gcc-wrapper-12.3.0.drv
/nix/store/sqmkkfapzykapcs4azvxm83n786ga7q1-gcc-wrapper-10.4.0.drv
/nix/store/vxnz30i23mkl4ldsq485kxn7q0p2y4nf-gcc-wrapper-8.5.0.drv
/nix/store/yfhv0bv15cg5kj2xsb9fcgb6pdlw42v0-gcc-wrapper-6.5.0.drv
/nix/store/yi5gr75pb6kddnll10jg25hhndhkba7s-gcc-wrapper-9.5.0.drv
$ for A in 10 11 12 13 4.8 4.9 6 7 8 9; do nix-instantiate . -A gcc$(echo $A | tr -d .); done | sort | tee after
/nix/store/1a37lnzpnz0dhm3lphiy2gcdrxgqa7ma-gcc-wrapper-4.8.5.drv
/nix/store/5szdivc8il0c3g94dq4wqnq5j77a9h6p-gcc-wrapper-11.4.0.drv
/nix/store/bmmc717wmnp1j2xkd3if5dfxicnflvn5-gcc-wrapper-7.5.0.drv
/nix/store/fc1ggpixv3wqcazchhl2hnn5zl5ds30l-gcc-wrapper-13.1.0.drv
/nix/store/j9c2b20w35r3ag5nxmklhagbwsgjhds2-gcc-wrapper-4.9.4.drv
/nix/store/nq7q57bxmsk2g457wr4b9449as3f216w-gcc-wrapper-12.3.0.drv
/nix/store/sqmkkfapzykapcs4azvxm83n786ga7q1-gcc-wrapper-10.4.0.drv
/nix/store/vxnz30i23mkl4ldsq485kxn7q0p2y4nf-gcc-wrapper-8.5.0.drv
/nix/store/yfhv0bv15cg5kj2xsb9fcgb6pdlw42v0-gcc-wrapper-6.5.0.drv
/nix/store/yi5gr75pb6kddnll10jg25hhndhkba7s-gcc-wrapper-9.5.0.drv
$ diff -u after before
$
Because the build still uses a pre-4.4 version of GNU Make,
this option makes the whole build serial rather than only
the installation.
See also https://gcc.gnu.org/PR109898
This reverts commit f3995cee01.
installing info files in parallel is dangerous, because
`install-info` will write to a `dir-file` as a side-effect,
and it has no protection against multiple `install-info`
processes running in parallel and overwriting each others'
changes.
Local fix until we can fix the `Makefile.in` generation
upstream
Fixes#229470
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.
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.
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`
Fixes build failure on `staging-next` introduced by commit c817efe6
("gcc: extend stripping of .a libraries and .o objects"):
...-bootstrap-stage3-stdenv-linux/setup: line 106: pushd: no other directory
Build failure happens because `libgccjit` has different `outputs` layout
compared to the rest of `gcc` derivations:
outputs = [ "out" "man" "info" ] ++ lib.optional (!langJit) "lib";
The change carves out `$lib` lib handling part to avoid `gcc` rebuild
in `staging-next`.
This commit factors out the conditional which creates the `lib64->lib`
symlink in the `preInstall` phase, and calculates its value in nix
code rather than bash code so touching it doesn't cause a global
rebuild on every platform.
On mips, gcc follows the somewhat awkward IRIX convention of putting
mips64 binaries in `lib64` and mips64n32 binaries in `lib32`. So on
mips64n32 we do not want the `lib64` symlinks.
With explicit support for distinction between Host and Target strip paths
we can now safely strip ELF binaries with their according strip tools
without fear of damaging binaries due to architecture mismatch.
Closure size change for `pkgsCross.mingwW64.gcc12Stdenv.cc.cc`:
# before:
$ nix path-info -Sh $(nix-build -A pkgsCross.mingwW64.gcc12Stdenv.cc.cc) | unnix
/<<NIX>>/x86_64-w64-mingw32-stage-final-gcc-debug-12.1.0 2.5G
# after:
$ nix path-info -Sh $(nix-build -A pkgsCross.mingwW64.gcc12Stdenv.cc.cc) | unnix
/<<NIX>>/x86_64-w64-mingw32-stage-final-gcc-12.1.0 1.5G
It's a follow-up to the breakage caused by 21966e13d2
("gcc: pass --with-build-sysroot=/"). It caused `pkgsLLVM`
cross-toolchain bootstrap breakage:
$ nix build --no-link -f. pkgsLLVM.hello
...
failed: /nix/store/...-x86_64-unknown-linux-gnu-stage-static-gcc-13.0.0.drv:
...
configure flags: ... --enable-languages=c --disable-multilib \
--disable-shared --enable-plugin ... --disable-libssp --disable-nls \
--without-headers --disable-threads --disable-libgomp --disable-libquadmath \
--disable-shared --disable-libatomic --disable-decimal-float --disable-libmpx \
--disable-bootstrap \
\
--build=x86_64-unknown-linux-gnu \
--host=x86_64-unknown-linux-gnu \
--target=x86_64-unknown-linux-gnu
...
The directory that should contain system headers does not exist:
/usr/include
make[2]: *** [Makefile:3279: stmp-fixinc] Error 1 shuffle=1658621302
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod
make[2]: Leaving directory '/build/build/gcc'
Note: it's a no-libc build. It's not expected to use any libc headers.
But in this case fixincludes tries to run and uses default /usr/include
location.
Fixinsludes is not normally expected to run during cross-compilation
on --without-headers. gcc/configure.ac:
: ${inhibit_libc=false}
if { { test x$host != x$target && test "x$with_sysroot" = x ; } ||
test x$with_newlib = xyes ; } &&
{ test "x$with_headers" = xno || test ! -f "$target_header_dir/stdio.h"; } ; then
inhibit_libc=true
fi
The change explicitly passes inhibit_libc=true to configure to disable
include fixing on such cases.
Fixed `nix build --no-link -f. pkgsLLVM.hello` toolchain bootstrap.
This reverts commit 8e48232180.
Since pkgsStatic.stdenv.cc can only produce static binaries, there's
no reason to include that compilers e.g. libstdc++.so.
linux-headers-5.13 removed <cyclades.h> along with device support.
Backport a single https://gcc.gnu.org/PR100379 upstream change to
fix gcc build.
Use local (unmodified) upstream patches to avoid fetchpatch dependency.
Okay, GCC might not technically support _every_ platform in
platforms.unix, but I think it would be easier to subtract those as
they're discovered, if that even matters, rather than trying to
exhaustively list every Unix it does support.
(I ran into this because I wanted to build GCC for NetBSD, which it
definitely supports.)
