In 6812dd98c4 I mistakenly had the
implication order reversed. This commit corrects that mistake.
The original assertion (which is correct) was the following, which
asserts that if you enable the GDB plugin, you must enable plugins
generally (there is shared infrastructure):
```
assert enableGdbPlugin -> enablePlugin;
```
When the option name was changed to `disableGdbPlugin`, I
incorrectly wrote:
```
assert disableGdbPlugin -> enablePlugin;
```
And then again incorrectly wrote:
```
assert disableGdbPlugin -> !enablePlugin;
```
This commit uses the correct equivalent for the first statement,
which is the contrapositive:
```
assert !enablePlugin -> disableGdbPlugin;
```
This commit adds an option `disableGdbPlugin` which controls whether
or not the plugin *for* GDB will be built. This plugin contains a
copy of `gcc`.
The configure flag that this option controls is called
`--disable-libcc1`. This flag name is slightly confusing: it is
used only by GDB (and apparently unmaintained), yet the flag name
does not mention GDB. This is why the option name is different from
the configure flag name.
The primary motivation for this commit is to allow the following PR
(which is not yet merged) to pass `--disable-libcc1` when building
the final native (build=host=target) compiler as part of the stdenv
bootstrap:
https://github.com/NixOS/nixpkgs/pull/209870
We need to `--disable-libcc1` in this scenario because gcc's build
machinery links `libcc1` against the `libstdc++` that is part of the
*compiler used to compile gcc*, rather than against the `libstdc++`
that is built *by* gcc. In an FHS distribution this distinction is
not terribly important because dynamically linked libraries are
late-bound (ld.so resolution). However in nixpkgs this causes a
reference back to the bootstrapFiles to leak all the way through to
the final stdenv.
More details can be found in the comment in
`pkgs/stdenv/linux/default.nix` of the PR linked above.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
Our openjdk derivations fail to build with `-march=opteron` (via
either `NIX_CFLAGS_COMPILE` or `hostPlatform.gcc.arch`). This was
fixed upstream in gcc12 but not carried back to gcc11:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d243f4009d8071b734df16cd70f4c5d09a373769https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910
Since gcc11 is still nixpkgs' primary compiler, this PR cherry-picks
the fix out of gcc12.
Unfortunately since `-march=` can be added after the `gcc11`
derivation is built we can't apply this patch conditionally (which
we don't usually do anyways).
the (vc4 redox) flex conditional was missing in all other gcc version
because gcc6 was the default at the time it was added
that is one of the problems common/dependencies.nix fixes
This reverts commit 2c931bd5f4.
The https://github.com/NixOS/nixpkgs/pull/209153 reverted --sysroot=/
change as it broke other astects of library search paths.
While it might still be useful to pull in gcc libraries when
non-standard --sysroot= is passed there are no meaningful use cases of
it in `nixpkgs` yet. Let's revert it for now.
On a native (host==build==target) build, `${with_build_sysroot}` can
be omitted. In that case, the line modified by this commit is
correct.
However, if `--with-build-sysroot=` is passed to `./configure`, then
`${with_build_sysroot}` will be used, similar to the cross case, and
the headers will be taken from:
${with_build_sysroot}${native_system_header_dir}
See:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=62bc908b991ff0b700225aef32743cd3d7c4daaf;hb=HEAD#l2439
This commit adjusts the comment to account for the case where
`--with-build-sysroot` is passed to a native compiler.
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.
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.
Without this change cross-built gcc fails to detect stack protector style:
$ nix log -f pkgs/stdenv/linux/make-bootstrap-tools-cross.nix powerpc64le.bootGCC | fgrep __stack_chk_fail
checking __stack_chk_fail in target C library... no
checking __stack_chk_fail in target C library... no
It happens because gcc treats search paths differently:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=446747311a6aec3c810ad6aa4190f7bd383b94f7;hb=HEAD#l2458
if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x ||
test x$build != x$host || test "x$with_build_sysroot" != x; then
...
if test "x$with_build_sysroot" != "x"; then
target_header_dir="${with_build_sysroot}${native_system_header_dir}"
elif test "x$with_sysroot" = x; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
elif test "x$with_sysroot" = xyes; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
else
target_header_dir="${with_sysroot}${native_system_header_dir}"
fi
else
target_header_dir=${native_system_header_dir}
fi
By passing --with-build-sysroot=/ we trick cross-case to use
`target_header_dir="${with_sysroot}${native_system_header_dir}"`
which makes it equivalent to non-cross
`target_header_dir="${with_build_sysroot}${native_system_header_dir}"`
Tested the following setups:
- cross-compiler without libc headers (powerpc64le-static)
- cross-compiler with libc headers (powerpc64le-debug)
- cross-build compiler with libc headers (powerpc64le bootstrapTools)
Before the change only 2 of 3 compilers detected libc headers.
After the change all 3 compilers detected libc headers.
For darwin we silently ignore '-syslibroot //' argument as it does not
introduce impurities.
While at it dropped mingw special case for no-libc build. Before the change
we passed both '--without-headers --with-native-system-headers-dir' for
no-libc gcc-static builds. This tricked darwin builds to find sys/sdt.h
and fail inhibid_libc builds. Now all targets avoid passing native headers
for gcc-static builds.
While at it fixed correct headers passing to
--with-native-system-headers-dir= in host != target case: we were passing
host's headers where intention was to pass target's headers.
Noticed the mismatch as a build failure on pkgsCross.powernv.stdenv.cc
on darwin where `sys/sdt.h` is present in host's headers (libSystem)
but not target's headers (`glibc`).
Co-authored-by: Adam Joseph <54836058+amjoseph-nixpkgs@users.noreply.github.com>
Without the change gcc-12 on musl fails to build due to system headers
poisoning:
/build/build/./prev-gcc/xg++ ... ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from /<<NIX>>/musl-1.2.3-dev/include/pthread.h:30,
from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
....
from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
from ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
from ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
/<<NIX>>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
84 | void *calloc(size_t, size_t);
| ^
/<<NIX>>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned "calloc"
124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
| ^
The change pulls upstream fix as is.
GCC 10 sets -fno-common by default. This broke some packages, so
when moving to GCC 10 we initially disabled this behavior. This
commit reverts that, bringing us closer to the standard and
upstream.
Co-authored-by: Sergei Trofimovich <slyich@gmail.com>
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.
