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.
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.
This causes some minor ugliness during stdenv bootstrap on powerpc64le
using cross-compiled bootstrap tools. MPFR wants to use decimal floats
by default so they have to be manually disabled in the configure flags
when using cross-compiled bootstrap tools.
The lineage of this particular configure flag traces back to 2010 (!)
It was added in commit: 9b1d5353a9
I've built various cross bootstrap tools and they seem to work fine,
so I don't think this is needed anymore.
In order to support stackprotector on musl32, this change import a
couple of patches from alpinelinux:
1. libssp_nonshared.a is built alongside musl's libc
2. the above library is automatically linked when compiling with gcc6
or gcc7
This is needed to build grub2 for powerpc64le hosts. Running powerpcle code
on powerpc64le is somewhat analogous to running multiarch i686 code on x86_64,
so it's also useful to have in general.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
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
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
This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
It's supposed to be just bugfixes. I tested building some projects with
gcc10. Also gfortran10 still builds. I don't expect issues.
This causes basically no rebuilds, as we use 9 by default.
Turns out that libgccjit gets installed as a .so file, which the gcc
builder.sh didn't change: It only touched .dylib files; that means
that anything linking in libgccjit.so would receive an "Image not
found" error at load time.
With this change, we invoke `install_name_tool` on .so files too,
adjusting their dynamic linker ID, so that they too can be found.
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).
In some cases, such as when building cross compilers, the binaries and
manpages contain the target architecture tuple, such as
`i686-w64-mingw32-g++.1`.
Ensure the symlink created to save space with the duplicated manpage
(`g++.1 -> gcc.1`) properly handles such cases and generates symlinks
such as `i686-w64-mingw32-g++.1 -> i686-w64-mingw32-gcc.1`.
Previously in such cases, a broken `gcc.1` link would be created
instead.
reasoning:
sjlj (short jump long jump) exception handling makes no sense on x86_64, it's forcably slowing programs down as it produces a constant overhead. On x86_64 we have SEH (Structured Exception Handling) and we should use that. On i686, we do not have SEH, and have to use sjlj with dwarf2. Hence it's now conditional on x86_32
`libstdc++` and a few other libraries are comiled with the options
set in `EXTRA_TARGET_FLAGS`. Normally, this is filled form
`EXTRA_FLAGS` inside of `builder.sh`, from which it inherits its
optimization option. For cross compilers `EXTRA_TARGET_FLAGS` is
set by a dedicated function that does not specify any optimization,
leading to sub-par runtime performance of many C++ programs.
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.
Everything is copied as-is from 9 (except version and hash).
Some platform-specific patches might not apply anymore;
I'm lazily leaving that for the community to fix.
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}.
MacOS 10.15 now includes "aligned_alloc". Disagreement between the
headers and the binaries about whether aligned_alloc exists leads to
a compilation failure (see #73319 and the detailed comment in this
commit).
Package is marked as broken for >2 years and used a fairly old
snapshot from the gcc7-branch, so I fairly doubt that this is
somewhere used (and is also pretty misleading as you don't expect a
random snapshot from gcc7 at `pkgs.gcc-snapshot`).
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
We don’t need to set -stdlib=libstdc++. This only works on Clang so it
is not good to set it globally. In addition, Clang knows to use
libstdc++ on Linux by default if no stdlib is set:
324f918438/lib/Driver/ToolChains/Linux.cpp (L456)
It’s a good policy to just leave off stdlib for now.
Fixes#29877.
* add generic x86_32 support
- Add support for i386-i586.
- Add `isx86_32` predicate that can replace most uses of `isi686`.
- `isi686` is reinterpreted to mean "exactly i686 arch, and not say i585 or i386".
- This branch was used to build working i586 kernel running on i586 hardware.
* revert `isi[345]86`, remove dead code
- Remove changes to dead code in `doubles.nix` and `for-meta.nix`.
- Remove `isi[345]86` predicates since other cpu families don't have specific model predicates.
* remove i386-linux since linux not supported on that cpu
Some packages don’t work correctly with pie. Here I disable it for:
- busybox
- linux kernel
- kexectools
I also get rid of the Musl conditional for disabling pie in GCC and
Binutils. Some day we might want to enable PIE without Musl and it
will be useful to have the *just* work with our compiler and linkers.
These don’t like having -fPIE set for them. We should disable
hardening all the time, but in the interest of not changing hashes,
this only disables it for Musl (where it is now the default).
(cherry picked from commit a3a6884649354a660326acd68c1bd08ffd2dcfa2)
- respect libc’s incdir and libdir
- make non-unix systems single threaded
- set LIMITS_H_TEST to false for avr
- misc updates to support new libc’s
- use multilib with avr
For threads we want to use:
- posix on unix systems
- win32 on windows
- single on everything else
For avr:
- add library directories for avrlibc
- to disable relro and bind
- avr5 should have precedence over avr3 - otherwise gcc uses the wrong one
Only apply w/musl since while it's wrong everywhere it apparently
hasn't broken things entirely w/glibc so keep things as they were.
Patch regenerated from original so that it applies
which isn't saying much since it's simple :).
Source:
https://patchwork.ozlabs.org/patch/154298/
IRC chat on #musl with Rich and others endorses this,
at least at the conceptual level of no shared library
should be using initial-exec TLS.
Fixes various uses of libgomp that previously crashed (before 1.1.20)
or encounter errors (post-1.1.20), such as pythonPackages.cython .
This isn't a MUSL thing, but just needed for cross compilation to x86.
No one had tried this when all cross compilation was to linux + glibc,
hence why no one noticed this until recently.
This has been not touched in 6 years. Let's remove it to cause less
problems when adding new cross-compiling infrastructure.
This also simplify gcc significantly.
Since years I'm not maintaining anything of the list below other
than some updates when I needed them for some reason. Other people
is doing that maintenance on my behalf so I better take me out but
for very few packages. Finally!
