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.
The x86_64-darwin build fails with the following symbol errors when
building gencondmd:
Undefined symbols for architecture x86_64:
"_ix86_excess_precision", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_fpmath", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_isa_flags", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_ix86_unsafe_math_optimizations", referenced from:
___cxx_global_var_init.101 in gencondmd.o
"_target_flags", referenced from:
___cxx_global_var_init.101 in gencondmd.o
This commit applies a workaround posted to the GCC BugZilla.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92061.
Darwin uses the clang integrated assembler, which does not support
`--gstabs`. While the `configure` script detects whether the assembler
supports it, Darwin passes `--gstabs` unconditionally. This patch is
backported to make the bootstrap only use it when supported.
Older versions of GCC use `-pipe` on Darwin due to compatibility
problems with older cctools assemblers. Darwin now uses the clang
integrated assembler. While it is possible to pipe input into it, the
wrapper used in nixpkgs is not set up for it.
Fixing the wrapper would cause all of Darwin to rebuild, which is not
desirable, so just disable `-pipe` in the bootstrap configuration. The
clang integrated assembler doesn’t have the bug anyway.
The libgcc configure script was middetecting aarch64-darwin and trying
to use a deployment target of 10.5, which is not valid for that
platform. The build was failing because the linker was looking for stubs
that don’t exist (neither as part of the source releases nor as part of
the official SDK from Apple).
Backporting the `config.host` check and `t-darwin-rpath` from GCC 12
allows GCC 11 to build again on aarch64-darwin.
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.
The rest of our gcc expression prepends "${targetPlatform.config}-"
to paths and binaries if `hostPlatform!=targetPlatform`. The
`libgcc.nix` expression was using
'hostPlatform.config!=targetPlatform.config`, which caused it to
look in the wrong place when moving files. This commit corrects that.
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>
It's not just gcc->clang cross compilation that produces different
platforms with equal configs — dynamic->static cross compilation can
have the same result (e.g. pkgsMusl.pkgsStatic). So, remove the check
for LLVM, but keep the check that the configs match.
This fixes pkgsMusl.nix on x86_64-linux, which depends on
pkgsMusl.pkgsStatic.buildPackages.gccWithoutTargetLibc.cc.
Fixes: 926c920c12 ("gcc: tighten condition for inhibit_libc=true")
The hash for pytensor is not correct, but that's also the case in
master, so a merge commit isn't the place to fix it.
Conflicts:
pkgs/development/python-modules/faadelays/default.nix
pkgs/development/python-modules/pytensor/default.nix
pkgs/tools/admin/rset/default.nix
Without the change `__FILE__` used in static inline functions in headers
embed paths to header files into executable images. For local headers
it's not a problem, but for headers in `/nix/store` this causes `-dev`
inputs to be retained in runtime closure.
Typical examples are `nix` -> `nlonhmann_json` and `pipewire` ->
`lttng-ust.dev`.
Ideally we would like to use `-fmacro-prefix-map=` feature of `gcc` as:
-fmacro-prefix-map=/nix/store/$hash1-nlohmann-json-ver=/nix/store/eeee.eee-nlohmann-json-ver
-fmacro-prefix-map=/nix/...
In practice it quickly exhausts argument lengtth limit due to `gcc`
deficiency: https://gcc.gnu.org/PR111527
Until it;s fixed let's hardcode header mangling if $NIX_STORE variable
is present in the environment.
Tested as:
$ printf "# 0 \"/nix/store/01234567890123456789012345678901-pppppp-vvvvvvv\" \nconst char * f(void) { return __FILE__; }" | NIX_STORE=/nix/store ./gcc/xgcc -Bgcc -x c - -S -o -
...
.string "/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-pppppp-vvvvvvv"
...
Mangled successfully.
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.
Without the change build on mips64-unknown-linux-gnu fails as:
$ nix-build -A buildPackages.gcc12 --argstr crossSystem mips64-linux
In file included from ...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/bits/stat.h:25,
from ...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/fcntl.h:78,
from ../../../../gcc-12.3.0/libsanitizer/sanitizer_common/sanitizer_linux.cpp:55:
...-glibc-mips64-unknown-linux-gnu-2.37-8-dev/include/bits/struct_stat.h:190:8: error: redefinition of 'struct stat64'
190 | struct stat64
| ^~~~~~
This PR sorts the huge pile of patches and deduplicates it. Unlike
its predecessors https://github.com/NixOS/nixpkgs/pull/249707 and
https://github.com/NixOS/nixpkgs/pull/250489 this commit *does*
affect eval.
Patches below are organized into three general categories:
1. Patches relevant to gcc>=12 on every platform
2. Patches relevant to gcc>=12 on specific platforms
3. Patches relevant only to gcc<12, sorted by the newest version to
which they might be relevant
