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.
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.
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.
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.
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.
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.
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.
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).
ARM ABIs now have a float field. This is used as a fallback to lessen
our use of `platform.gcc.float`. I didn't know what the MIPs convention
is so I kept using `platform.gcc.float` in that case.
Shea Levy