gcc-12 did a mass rename from .c to .cc c++ files. As a result build fails as:
substitute(): ERROR: file 'gcc/config/darwin-c.c' does not exist
Closes: https://github.com/NixOS/nixpkgs/issues/172877
Programs compiled with gdc (such as tumiki-fighters and torus-trooper)
that depend on c++ libraries were failing with errors such as
/nix/store/3fqi6nigj8dkbvjnw8y4dy59gkq8vsj4-binutils-2.38/bin/ld: /nix/store/36960p41h83cwkcs2vpzg8ni39w4sc5m-bulletml-0.0.6/lib/libbulletml.so: undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
because of the mismatch with the gcc version used to compile the
libraries.
This commit unpins the gcc version gdc is based on, so they are kept in
sync.
gdc9 was removed since no other package depends specifically on that
version
Without the change mingw32-gcc fails to build as:
In file included from /build/gcc-11.2.0/libstdc++-v3/libsupc++/cxxabi.h:49,
from ../../../../gcc-11.2.0/libstdc++-v3/libsupc++/atexit_thread.cc:24:
../../../../gcc-11.2.0/libstdc++-v3/libsupc++/atexit_thread.cc:36:3: error: 'int __cxxabiv1::__cxa_thread_atexit(void (*)(void*), void*, void*)' should have been declared inside '__cxxabiv1'
36 | _GLIBCXX_NOTHROW
| ^~~~~~~~~~~~~~~~
../../../../gcc-11.2.0/libstdc++-v3/libsupc++/atexit_thread.cc:34:1: error: conflicting declaration of C function 'int __cxxabiv1::__cxa_thread_atexit(void (*)(void*), void*, void*)'
34 | __cxxabiv1::__cxa_thread_atexit (void (*dtor)(void *),
| ^~~~~~~~~~
The change follows upstream change introduced in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2
Without this patch, linking when cross-compiling fails:
Undefined symbols for architecture arm64:
"_host_hooks", referenced from:
gt_pch_save(__sFILE*) in libbackend.a(ggc-common.o)
gt_pch_restore(__sFILE*) in libbackend.a(ggc-common.o)
toplev::main(int, char**) in libbackend.a(toplev.o)
ld: symbol(s) not found for architecture arm64
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.
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.
Update all usage of lib.concatStrings (lib.intersperse ...) to
lib.concatStringsSep. This produces the same result as per https://github.com/NixOS/nixpkgs/pull/135843,
however it yields a performance benefit on Nix versions that
support the builtins.concatStringsSep primop.
When upgrading from gcc 9 to 10, avr-gcc started to hit the hydra log
limit, preventing the binary cache from being populated.
This commit tries to workaround this issue by passing `-s` to make for
avr-gcc 10 and 11 which seem to exhibit this problem.
Reference #135605.
libgomp has been disabled on musl since musl support was first added to
nixpkgs (15d401dcfa), but seems to work
fine. Tested down to gcc 6 (gcc 4.8 already doesn't build for musl)
According to https://wiki.osdev.org/GNAT_Cross-Compiler building
libada is not possible when building a cross compiler. Unfortunately I
haven't been able to determine if this is upstream's position as well,
but sure enough disabling libada lets us build a GNAT cross compiler.
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.
