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.
This should fix a few broken cc-wrapper tests that also check for
libasan[1][2][3]:
[...]
checking whether sanitizers are fully functional... ==243==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22)
[...]
The underlying issue is that `SIGSTKSZ` isn't a compile-time constant
anymore, but in this case the uninitialized `kAltStackSize` was
initialized early enough to evalute to `0`[4].
The issue is already fixed in gcc11 and there's GCC 8.5 which also
contains the patch, however the backports to v9 and v10 aren't released
yet, so we have to apply patches on our own here.
For GCC 7.5 I applied the patch from gcc8 as it doesn't seem as if
there's an official upstream backport.
[1] https://hydra.nixos.org/build/163102264
[2] https://hydra.nixos.org/build/163624687
[3] https://hydra.nixos.org/build/163619227
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
This reverts commit d71611fb72, reversing
changes made to cae9272c92.
The update caused an issue on aarch64-linux where it's the default
compiler, many packages got broken (usually through `mariadb`; I think).
File lib/gcc/aarch64-unknown-linux-gnu/9.4.0/include/arm_acle.h
got unbalanced braces (look at `cplusplus` lines), e.g. see in
/nix/store/fvkdvx69sf8h99xgx0m42dzfd5ly5csr-gcc-9.4.0/
I don't know how exactly it happened, as in the source this header is OK
and hasn't even changed between 9.3.0 and 9.4.0. I assume that some
post-processing on headers got broken. Anyway, I don't have much
motivation to dig deeper here, but perhaps someone else will.
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.
This patch was applied to gcc7 in aab8c7ba43 ("netbsd: add cross target"),
but it hasn't been brought forward to newer compilers that have the
same problem.
GCC 6 and (probably) GCC 4.9 also have the issue, but the patch
doesn't apply cleanly to them so I'm leaving them alone for now.
GCC 10, our current default, appears to have finally fixed this.
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.
When cross compiling to the same kernel / arch combination, it is safe
to use strip of libraries. This happens when cross-compiling musl
programs. dontStrip is now set in each gcc compiler instead of in
gcc/builder.sh.
Fixes#75476
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
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
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.
libgccjit is a library but is used as a compiler. So it references a
bunch of compiler things in $out. To avoid a cycle, we need to put
everything in $out, so referenced to $lib need to be replaced with
${!outputLib}.
Shea Levy