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.
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.
