| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
This reverts commit 3f46cdcb5b903fe1c07707fea9ee24ae09d964b2.
|
| |
|
|
|
|
|
| |
This reverts commit ab66640da31a80c4cfd38e8f495c23ef2f7e254b, reversing
changes made to c08b005e0f6ce26d0269e9ac7e12747a29f822fb.
The changes were merged without the associated bootstrap updates.
|
| |
|
|
|
|
|
|
| |
Include all runtime object files in output package, enabling different
kinds of build modes - non-PIE, PIE, static PIE and profile-generated.
Suggested by @trofi:
https://github.com/NixOS/nixpkgs/pull/252310#issuecomment-1709425791
|
| | |
|
| |\
| |
| | |
pkgsCross.loongarch64-linux.freshBootstrapTools.bootstrapFiles: fix build
|
| | | |
|
| |/
|
|
|
|
| |
musl now supports RISC-V. Let's centralise musl availability checks
in musl.meta.platforms, so we don't have to keep cleaning up ad-hoc
checks like this all over the tree.
|
| |
|
|
|
|
|
|
|
|
|
| |
The comment stating that "GCC has certain things built in
statically" is no longer true as of
https://github.com/NixOS/nixpkgs/pull/209870. Moreover, as pointed
out in https://github.com/NixOS/nixpkgs/pull/228130 this
optionalString block no longer builds for
pkgsCross.*.freshBootstrapTools.
It is safe to drop this clause now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our bootstrap-files unpacker has always relied on a lot of unstated
assumptions, one of them being that every library has a DT_NEEDED
for librt.so, so patchelf'ing something into the RUNPATH into
librt.so means that it will be searched for every library load in
all of the bootstrap-files.
Unfortunately that assumption is not true for libgcc.
This causes problems, because patchelf links against libgcc (and
against libstdc++, which links against libgcc). So we can't use
patchelf on libgcc, because it needs libgcc, so patchelf doesn't
work until libgcc is patchelfed.
The robust solution here is to use static linking for the copy of
patchelf that is shipped with the bootstrap-files. We don't have to
go all the way to a statically linked libc; just -static-libgcc and
-static-libstdc++ are enough to break the circular dependency.
|
| |
|
|
|
|
| |
We do not want to preserve the symlinks from libgcc_s, since they
point to another outpath. We want to copy from that outpath rather
than link to it.
|
| |
|
|
|
|
| |
Now that we've dropped the
gcc-links-statically-to-lib{isl,mpfr,mpc,gmp} hack, our gcc needs
libisl.so. Let's add it to the bootstrap-files.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
pkgs/development/libraries/qt-6/modules/qtbase.nix
pkgs/stdenv/linux/make-bootstrap-tools.nix
|
| | |
| |
| |
| |
| |
| |
| |
| | |
`builtins.baseNameOf` retains any string context, causing the test
derivation to incorrectly depend on `pkgs.glibc`. All we really want is
to know what the dynamicLinker is called, but we don't need it to be
present in store.
Thanks to Adam Joseph for spotting this.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After https://github.com/NixOS/nixpkgs/pull/209054 we started moving
libstdc++.so out of default glibc's paths. This exposed bootstrap
tools build failure as:
$ nix build --no-link -f ./pkgs/stdenv/linux/make-bootstrap-tools.nix
...
>
.../bin/bar: error while loading shared libraries: libstdc++.so.6:
cannot open shared object file: No such file or directory
Note that bootstrap itself did not break. The change only expands
handcrafted `-rpath` entries.
|
| |
|
|
|
|
|
| |
gcc stopped using libelf in commit 48215350c24 ("re PR lto/46273 (Failed
to bootstrap)") around 2010, before gcc-4.6.0.
Bootstrap tools don't use it either.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's expected that attributes in the top-level package set will all use
that package set, but this wasn't the case for the bootstrap tools.
This led some very confusing behaviour:
- pkgsMusl.stdenvBootstrapTools would build glibc bootstrap tools
- stdenvBootstrapTools was _always_ cross compiled, even if
Nixpkgs wasn't, because it always set crossSystem. This also didn't
match the behaviour of using make-bootstrap-tools.nix as an
entrypoint, where crossSystem would default to null.
For the Linux stdenv, I've made the ideal fix, which is to make pkgs an
argument rather than taking the arguments for pkgs, and then
re-importing it. This means it'll always use exactly the same package
set that's calling it, and should also mean faster eval due to not
importing Nixpkgs twice.
The Darwin stdenv is more complicated, and I'm not able to easily test
it, so I wasn't confident in making the same fix there. Instead, I've
just made sure crossSystem and localSystem are set to the correct values
so they're not always cross compiled and match the parent package set's.
It would still be preferable if somebody could make Darwin's
make-bootstrap-tools.nix take pkgs as an argument, rather than all the
arguments for pkgs.
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
This time without rebuilding stdenvs.
|
| | | |
|
| |/
|
|
| |
Co-authored-by: TredwellGit <tredwell@tutanota.com>
|
| | |
|
| |
|
|
| |
This is needed after glibc bump from PR #111616.
|
| |
|
|
| |
(And fix an ofborg eval error btw)
|
| |
|
|
|
| |
Now that powerpc64 is always ELFv2, we can unconditionally use musl
tools here.
|
| |\
| |
| | |
Enable PPC64 (big-endian)
|
| | |
| |
| |
| | |
Also check for powerpc64-linux-elfv1, which does not support musl.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The dynamic loader on powerpc64 is called ld64.so.2 rather than
ld-linux.so.*, and was not matched by the existing pattern.
We reuse the dynamicLinker name from binutils to match a wider set
of platforms and to avoid specifying this information in two places.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Increase schedulingPriority of the bootstrap tools to unblock the
nixpkgs-unstable channel.
The channel is repeatedly blocked by the makeBootstrapTools job for
aarch64. The cause is lack of resources.
By increasing the priority, it should become the first job Hydra would
build, allowing the channel to advance quicker. Of course, it does mean
that while the channel advances, nothing else has been built.
This should be a temporary solution until we have more capacity for
aarch64.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There's a generated header that got comment about the source header
from glibc.dev, which added unwanted runtime dependency. Tested:
nix build -f pkgs/top-level/release.nix stdenvBootstrapTools.{aarch64,i686,x86_64}-linux.test
|
| |
|
|
|
|
|
| |
Apparently this option trades compression time for size,
and explicitly does so without increasing resources needed in decomp.
Doesn't make tarball creation unbearable, so add it to options!
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
* pr-46056:
binutils: use shared libs
binutils: fix #44936 the huge size regression
|
| | | |
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since gcc.lib/lib64 is a symlink to 'lib', the use of
"lib*/libgcc_s.so*" triggered a warning (error) with
the latest coreutils. Essentially we were doing:
$ cp a/x b/x y/
And latest coreutils rejects such invocations.
Just copy from 'lib', lib64 is a link to it anyway.
* Nothing else in this file bothers looking at lib*
* AFAICT lib* only ever possibly matched lib64 anyway
|
| | |
| |
| |
| |
| |
| | |
This allows cross builds to work. Evidentallyy this has been done wrong
since I combined the bootstrap tool creation files in
ab651d2c9bab620ebe5e515476fbd70d2c5b0c61. Oops!
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
We go out of our way (see top of file) to build a single binary
with symlinks for all of the tools, but were losing them
when preparing the bootstrap tools.
|
| |\ |
|
| |/
|
|
| |
Fixes #35089
|
| |
|
|
| |
x86_64 bootstrap tarball goes from 37M -> 21M (!)
|
| |
|
|
|
| |
This is the same in current cases AFAICT,
other than uses musl instead of glibc when musl-native.
|
| | |
|