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; }
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.
Without the change build fails against gcc-11 as:
```
../../gcc-4.8.5/gcc/reload1.c:89:24:
error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17
89 | (this_target_reload->x_spill_indirect_levels)
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
```
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
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.)
gcc's configure system has the nasty habit (for us) of judging for
itself if it is building a cross compiler (or cross compiling), but on
the limited information of the build, host and target platforms' config
which only contains a subset of the information we encode in
`stdenv.*Platform`. The practical consequence was that prior to this
change building `pkgsLLVM.buildPackages.gcc` actually fails because it
refuses to use `--with-headers` with something it believes to not be a
cross compiler.
As a workaround we force the appropriate variable in the configure
script to always be `yes` regardless of its own conditional check.
At some point we probably should report this issue in some capacity, so
future gcc versions don't force us into workarounds like this and
acdc783418.
Don't rely on gcc detecting from the passed platforms which prefix to
use, but always specify the prefix nixpkgs expects (or doesn't). This
allows us to work around problems where the configure script would add
prefix where nixpkgs doesn't expect one (if `--target` was specified,
but the same as `--host`) or doesn't add one if nixpkgs expects one (if
`--target` and `--host` are the same, but we are actually cross
compiling, but the relevant parts of the platform are not encoded into
the platform config.
See also ca9be0511b.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
This option can be used to set the “jit” language which enable the
libgccjit functionality. Also adds a “libgccjit” attr which is gcc
built with just jit enabled.
