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.
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.
Our gcc builder creates lib64->lib links to ensure that the "primary"
libraries for the targetPlatform wind up in $PREFIX/lib. This is
required in order for make-bootstrap-files.nix to work correctly.
On mips, gcc follows the somewhat awkward IRIX convention of putting
mips32 binaries in `lib` and mips64n32 binaries in `lib32`. So we
need similar symlinks there. This may come up on other ILP32
platforms as well, so a general-purpose variable name is provided.
The initial intent was to strip .a and .o files, not .a.o files.
While at it expanded stripping for $lib output as well.
Without the change `libgcc.a` was not stripped and `.debug*` sections
made into final binaries. It's not a problem on it's own, but it's an
unintended side-effect. Noticed on `crystal_1_0` test failure where
`crystal` was not able to handle `dwarf-5`.
While at it allowed absolute file names to be passed to stripDebugList
and friends.
