- Pass --with-multilib-list=m4,m4-nofpu for SH4 so the kernel can use
-m4-nofpu. Move libraries out of !m4/ multilib subdirectory in
postInstall before moveToOutput.
- Generate sysroot-suffix.h for SH4 in the standalone libgcc builder.
- Add linux-kernel.target = "vmlinux" and installTarget for SH4.
All changes scoped to isSh4 to avoid rebuilds on other platforms.
Rather than implementing this at the wrapper level (which has been
attempted but not merged in # 252310 and # 205031), configuring GCC
directly with --enable-default-pie is simple and matches mainstream
distribution practices. Packages that cannot build with PIE can
explicitly pass -no-pie when needed, and mostly already do
due to the prevalence of GCCs built with this flag.
Requires followup to decide what to do with "pie" flag.
GDC 11 was the last version that could bootstrap without a D compiler,
and GDC don’t offer their own binaries any more. GCC 11 is now
end‐of‐life and being removed (as is GCC 12, even).
It’s possible that we could use another distribution’s binary
packages to bootstrap this, or go via our DMD package (it’s
apparently not possible to bootstrap GDC with LDC, but I’m not sure
about DMD), but as nobody has worked on it in the three years since
GCC 12 came out, it seems like interest is limited, and it’s more
of a yak shave than I’m up for right now.
A full from‐source bootstrap chain would of course be nice, but is
more the realm of the minimal bootstrap work than something we’d
want to keep GCC 11 around in the main package set indefinitely for.
Missing these weren't causing any issues because they only require
headers, and gcc was likely using newlib headers. However, these
features must be disabled for `libc = null;` to work properly.
Passing --with-ld causes problems when injecting a custom linker
wrapper (similar to useMoldLinker) because it causes collect2 to
check the --with-ld path (which is a hardcoded path to the standard
linker wrapper) before $PATH, whereas with custom linker wrappers we
want gcc to search $PATH.
Because binutils-wrapper is not guaranteed to be present in $PATH,
prepend it to $PATH in cc-wrapper.
I verified that -print-prog-name=ld still prints an appropriate
value. For example, when cross compiling for x86_64 on an aarch64
machine, the following is printed by the util-linux configure script
(which uses -print-prog-name=ld [1]):
checking for ld used by x86_64-unknown-linux-gnu-gcc... x86_64-unknown-linux-gnu-ld
We still pass --with-as because the gcc spec file relies on this
to find the assembler. This is probably fine for now as it is less
common to want to override the assembler than the linker.
[1] https://sources.debian.org/src/util-linux/2.41-4/m4/lib-ld.m4/?hl=59#L59
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
The GCC bootstrap builds each stage with an unwrapped GCC, which needs
to correctly handle looking for libraries and headers in sysroot.
Setting the native header folder to `/usr/include` will actually cause
GCC to search `<sysroot>/usr/include`, which is the SDKROOT in nixpkgs.
When build platform and host platform differ, but have the same
triple, the code in nixpkgs will consider it a cross compilation,
but gcc won't. This will lead some derivations to look for c++
headers in the wrong place. To solve this always output the headers
in the non-cross location, like we do for the other gcc headers
already.
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
| ^~~~~~
We want a `libgcc_s.so` to be built by the first stage
cross-compiler (withoutTargetLibc), since that is the compiler which
will compile the target libc.
This commit accomplishes that, by making three changes:
1. Replacing the `targetPlatform.libc == "msvcrt" &&` conditional
with `enableShared`, so that the code which cross-build
`libgcc_s.so` is used for all cross compilers capable of emitting
shared libraries.
2. Removing the `targetPlatform == hostPlatform` guard from the code
which produces the `libgcc` output.
3. Looking for build products in in "lib/${targetPlatform.config}/"
rather than "lib/", so we will find them when cross compiling.
This commit allows `gccCrossStageStatic` to build dynamically-linked
libraries. Since is no longer restricted to building static
libraries its name is no longer appropriate, and this commit also
renames it to the more-accurate `gccWithoutTargetLibc`.
By default, you can't build a gcc that knows how to create dynamic
libraries unless you have already built the targetPlatform libc.
Because of this, our gcc cross-compiler is built in two stages:
1. Build a cross-compiler (gccCrossStageStatic) that can build
only static libraries.
2. Use gccCrossStageStatic to compile the targetPlatform libc.
3. Use the targetPlatform libc to build a fully-capable cross
compiler.
You might notice that this pattern looks very similar to what we do
with `xgcc` in the stdenv bootstrap. Indeed it is! I would like to
work towards getting the existing stdenv bootstrap to handle cross
compilers as well. However we don't want to cripple `stdenv.xgcc`
by taking away its ability to build dynamic libraries.
It turns out that the only thing gcc needs the targetPlatform libc
for is to emit a DT_NEEDED for `-lc` into `libgcc.so`. That's it!
And since we don't use `gccCrossStageStatic` to build anything other
than libc, it's safe to omit the `DT_NEEDED` because that `libgcc`
will never be loaded by anything other than `libc`. So `libc` will
already be in the process's address space.
Other people have noticed this; crosstool-ng has been using this
approach for a very long time:
36ad0b17a7/scripts/build/cc/gcc.sh (L638-L640)
The 4aa95e3312 commit added support for
aarch64-darwin but also ignored platform flags if the build platform
is aarch64-darwin. This leads to confusing errors such as
`pkgsCross.raspberryPi` packages compiled with soft-float even though
the platform supports hard-float (and is built as such on other
platforms).
The correct way to ignore platform flags is to check `targetPlatform`,
not the build platform. This change fixes that.
While we're here, tigthen the special-case to cover only the problematic
flags: `-with-cpu` and `-with-arch`.
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>
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.
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; }
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>
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>
