- 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.
This will break GCC < 13 when compiled with LLVM, but those versions
are EOL and should be removed anyway, so I’m happy to do the nudge
rather than spend more effort on this hopefully‐temporary hack.
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.
In libgcc.nix, `targetPlatformSlash` is set by checking if hostPlatform == targetPlatform.
In default.nix, `targetConfig` (which is also going to be part of the path) is also set by checking if hostPlatform == targetPlatform.
However, in common.nix, the recently added `isCross` is set by checking if hostPlatform.config == targetPlatform.config.
This means that for platforms like '-nolibc' the paths in common.nix are not set up correctly for libgcc.nix to find and move libgcc_s.so .
Changing isCross to also check hostPlatform == targetPlatform fixes this issue.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 78e9caf153
result/bin/apply-formatting $NIXPKGS_PATH
Those would be problematic with __structuredAttrs turned on, because
they'd turn those nice bash arrays back into strings - and potentially
lose some of the values on the way.
The original logic was prepending to the array, but this one prepends
the array to itself, which breaks the x86_64-linux stdenv bootstrap. The
correct thing to do is build up the arguments in a temporary array and
prepend it like the original code was doing.
Fixes
/nix/store/8pq96x5qsczrmc926795lf7j4dzy2c8q-binutils-patchelfed-ld-2.43.1/bin/ld: ../../src/liblzma/.libs/liblzma.so: undefined reference to `__pthread_cond_timedwait64'
collect2: error: ld returned 1 exit status
while building `xz` for `stdenv`. The root cause is that glibc replaced
`__USE_TIME_BITS64` with `__USE_TIME64_REDIRECTS`[1]. However, the
stage3 GCC seems to use the bootstrap headers from glibc for
`fixincludes`, i.e. headers w/o this change. Because of that, the xz
build with stage3 stdenv gets a header that looks like this:
# ifndef __USE_TIME_BITS64
/* ... */
# else
# ifdef __REDIRECT
/* ... */
# else
# define pthread_cond_timedwait __pthread_cond_timedwait64
# endif
# endif
Since __USE_TIME_BITS64 doesn't exist anymore because a new glibc is used
for building, the preprocessor ends up in the condition defining
`__pthread_cond_timedwait64` even though it's not supposed to end up
there since __pthread_cond_timedwait64 doesn't exist on x86_64[2].
I decided to just kill the header here since GCC claims that all the
`pthread.h` only very old glibc versions or platform-specific libcs we
don't use[3].
[1] https://sourceware.org/git/?p=glibc.git%3Ba%3Dcommit%3Bh%3Ddd535f4f19ef2b5c367a362af445ecadcf45401e
[2] https://inbox.sourceware.org/libc-stable/50c0269d-b73c-4e8a-9816-65f72d6082c0@linaro.org/
[3] https://github.com/gcc-mirror/gcc/blob/releases/gcc-14.2.0/fixincludes/inclhack.def
Darwin uses absolute path install names, so setting rpaths is unnecessary. This fixes breakage on older versions of GCC that try to set a deployment target that does not support rpaths.
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`.
The change reverts commit 7df4387ebd
A few reasons to revert the commit:
1. The change was not enough to restore `-idirafter` override semantic
to match unwrapped compiler.
2. The change broke override semantics for cross-compilers
3. The change made override semantics different between cross-compiler
and native compiler
All of three have some overlap between, but I think it's important
to call all of them out.
The main fallout is the uboot builds, reported by cynerd.
Used the following test to check the override recovery:
$ nix shell github:NixOS/nixpkgs/release-22.05#pkgsCross.aarch64-multiplatform.stdenv.cc
$$ cat stdio.h
# empty
$$ printf "#include <stdio.h>" | aarch64-unknown-linux-gnu-gcc -E - -o - -idirafter . >/dev/null; echo $?
0
It failed before the change and succeded after.
Now that we use the standard builder, the commands produced by
pre-configure.nix are wrapped in a bash function. Inside of a bash
function, `export foo=` will still add `foo` to the environment of
any child processes forked after that point, but those variables
will *not* be visible to bash code which is outside of the
function-scope in which the `export` occurs.
Weird crap like this is yet another reason why we need to move away
from using bash for logic. Let's switch.
The bash `declare` builtin works differently when it occurs inside
function, as it now does due to breaking up the monolithic
`builder.sh` into separate phases. We have to add `-g` in order to
get the outside-of-a-bash-function behavior when using `declare`
within a bash function.
This commit adds arguments to `builder.nix`, making it a callable
function, and splits up the single massive shell script into
separate attributes for each phase. It also drops the first two
lines and the last line because these are part of the default
builder.
All script lines which were not part of a phase function have been
moved into `preUnpack` since this is the first phase that runs.
Subsequent commits will move parts of this to more sensible
locations.
This commit performs two search-and-replace operations:
- replace all `${` with `''${`
- replace `''` with `""` in shell scripts
This commit is left unsquashed to make review of the subsequent
commits easier.
