When native-compiling, gcc will install libraries into:
/nix/store/...-$targetConfig-gcc-$version-lib/lib
When cross-compiling, gcc will install libraries into:
/nix/store/...-$targetConfig-gcc-$version-lib/$targetConfig
When cross-compiling, we intended to create a link from $lib/lib to
$lib/$targetConfig, so that downstream users can always safely
assume that "${lib.getLib stdenv.cc.cc}/lib" is where the gcc
libraries are, regardless of whether `stdenv.cc.cc` is a cross
compiler or a native compiler.
Unfortunately, there were two problems with how we were trying to
create these links:
1. The link would be created only when `enableLibGccOutput==true`
2. The link was being created from the incorrect source
`$lib/lib/lib` instead of `$lib/lib`.
Both of these mistakes are my fault. This commit corrects them by
creating the link using `ln -Ts` (which is more predictable) and by
creating the link from `gcc/common/builder.nix` rather than from
`gcc/common/libgcc.nix`.
this equates to -ftrivial-auto-var-init=pattern
clang has removed support for -ftrivial-auto-var-init=zero and
are unlikely to re-add it, so use -ftrivial-auto-var-init=pattern
on both compilers if only to make behaviour more consistent
between the two.
add to pkgsExtraHardening's defaultHardeningFlags.
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.
while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.
mkDerivation can still easily refer to either when it is constructed.
this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.
this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
Building a cross-compiler fails due to register storage class specifier
errors when building with clang 16 due to its defaulting to C++17.
Downgrading the error allows the older cross-compilers to build.
darwin.cctools defaults to `llvm-strip` when the version of LLVM in the
stdenv is 12 or newer. This strip implementation does not support the
`-c` flag required by older versions of GCC. Use the cctools-port
version for compatibility when building older versions of GCC.
According to Hydra, the last time GCC 4.8 successfully built on Darwin
was October 2014. It is possible to make the first stage build
successfully with clang, but the resulting GCC is not capable of reading
the Darwin SDK headers due to their use of `__can_include`.
It’s been broken for almost a decade, so just disable it.
This commit changes the target suffix for the first-stage cross
compiler from `-stage-static` to `-nolibc`, and eliminates the
target suffix from the final-stage cross compiler (previously
`-stage-final`).
Co-authored-by: Artturi <Artturin@artturin.com>
Co-authored-by: John Ericson <git@JohnEricson.me>
For a cross-built native compiler, i.e. build!=(host==target), the
bundled libgfortran needs a gfortran which can run on the
buildPlatform and emit code for the targetPlatform. The compiler
which is built alongside gfortran in this configuration doesn't meet
that need: it runs on the hostPlatform.
This commit passes the necessary compiler via `GFORTRAN_FOR_TARGET`,
using `pkgsBuildTarget.gfortran`.
Cross-compiled binaries currently end up with two different libgcc
outpaths in their closure. This is harmless, but confusing.
The two libgccs are:
- One of them is the "first" targetPlatform libgcc, which is built
by the "first" cross-compiler. This "first libgcc" and "first
compiler" are used to build the targetPlatform glibc.
- Once glibc is built, we *rebuild* the cross-compiler, since gcc
can't enable most of its features unless you give it an
already-compiled targetPlatform glibc. When this "second"
compiler is built, it also builds an extra copy of libgcc.
This commit discards the second, extra libgcc, and instead puts a
reference to the first (correct) libgcc into the "second compiler"
`.passthru.libgcc`, so that anybody expecting `stdenv.cc.cc.libgcc`
to exist will still find it there.
Closes#249680
msvcrt is only one of the libcs in MinGW. We therefore
replace explictly testing for msvcrt with the isMinGW
predicate. This lays the foundation for ucrt64 support.
