| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Also check for powerpc64-linux-elfv1, which does not support musl.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ppc64le enablement
* gcc, glibc: properly handle __float128
* lib/systems, stdenv: syntax cleanup
* gcc7: remove ugly hack
* gcc: add/update __float128 flags
* stdenv: add another pair of quotes for consistency
* gcc: move __float128 flag for ppc64le-glibc into common/platform-flags.nix
|
| |
|
|
|
| |
Not terribly difficult to get this working, but until it does
remove it so the cross jobset doesn't have the failures this introduces.
|
| |
|
|
| |
Fixes #35089
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
libgcc.a and similar
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- Compiler's shouldn't use `binutils.dev` as that doesn't yet exist
with a cross binutils.
- Last two `binutils.binutils` which weren't reverted
|
| |
|
|
| |
Now the NixOS tarball job succeeds again
|
| |
|
|
|
|
| |
buildDepends
It now has the correct wrapped tools and nothing else is needed.
|
| |
|
|
| |
This is good for maintenance and education.
|
| | |
|
| |
|
|
|
| |
This is a cross derivation---it's built on one platform to run on
another---so let's structure it like all the other cross derivations.
|
| |
|
|
|
|
|
|
| |
`pkgsNoParams` was removed by me, but then #25035 was merged using it,
leading to an unbound identifier.
It would be nice to get travis to do build release-cross.nix or
something to catch these things.
|
| |\
| |
| | |
Add some ARM platforms
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use `buildPackages.binutils` to get build = host != target binutils,
i.e. the old `binutilsCross`, and use
`buildPackages.buildPackages.binutils` to get build = host = target
binutils, i.e. the old `binutils`.
`buildPackages` chains like this are supposed to remove the need for
all such `*Cross` derivations. We start with binutils because it's
comparatively easy.
No hashes of cross-tests should be changed
|
| |/ |
|
| |
|
|
| |
Apparently our native bzip2 builds switched to using dynamic libraries at some point.
|
| |
|
|
| |
Broken after commit 17a344a ("binutils: Add lib output").
|
| |\
| |
| | |
Aarch64 (ARM64) support
|
| | | |
|
| |/
|
|
|
| |
This was just done temporarily on the last cross-overhauling PR for
testing purposes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[N.B., this package also applies to the commits that follow it in the same
PR.]
In most cases, buildPackages = pkgs so things work just as before. For
cross compiling, however, buildPackages is resolved as the previous
bootstrapping stage. This allows us to avoid the mkDerivation hacks cross
compiling currently uses today.
To avoid a massive refactor, callPackage will splice together both package
sets. Again to avoid churn, it uses the old `nativeDrv` vs `crossDrv` to do
so. So now, whether cross compiling or not, packages with get a `nativeDrv`
and `crossDrv`---in the non-cross-compiling case they are simply the same
derivation. This is good because it reduces the divergence between the
cross and non-cross dataflow. See `pkgs/top-level/splice.nix` for a comment
along the lines of the preceding paragraph, and the code that does this
splicing.
Also, `forceNativeDrv` is replaced with `forceNativePackages`. The latter
resolves `pkgs` unless the host platform is different from the build
platform, in which case it resolves to `buildPackages`. Note that the
target platform is not important here---it will not prevent
`forcedNativePackages` from resolving to `pkgs`.
--------
Temporarily, we make preserve some dubious decisions in the name of preserving
hashes:
Most importantly, we don't distinguish between "host" and "target" in the
autoconf sense. This leads to the proliferation of *Cross derivations
currently used. What we ought to is resolve native deps of the cross "build
packages" (build = host != target) package set against the "vanilla
packages" (build = host = target) package set. Instead, "build packages"
uses itself, with (informally) target != build in all cases.
This is wrong because it violates the "sliding window" principle of
bootstrapping stages that shifting the platform triple of one stage to the
left coincides with the next stage's platform triple. Only because we don't
explicitly distinguish between "host" and "target" does it appear that the
"sliding window" principle is preserved--indeed it is over the reductionary
"platform double" of just "build" and "host/target".
Additionally, we build libc, libgcc, etc in the same stage as the compilers
themselves, which is wrong because they are used at runtime, not build
time. Fixing this is somewhat subtle, and the solution and problem will be
better explained in the commit that does fix it.
Commits after this will solve both these issues, at the expense of breaking
cross hashes. Native hashes won't be broken, thankfully.
--------
Did the temporary ugliness pan out? Of the packages that currently build in
`release-cross.nix`, the only ones that have their hash changed are
`*.gcc.crossDrv` and `bootstrapTools.*.coreutilsMinimal`. In both cases I
think it doesn't matter.
1. GCC when doing a `build = host = target = foreign` build (maximally
cross), still defines environment variables like `CPATH`[1] with
packages. This seems assuredly wrong because whether gcc dynamically
links those, or the programs built by gcc dynamically link those---I
have no idea which case is reality---they should be foreign. Therefore,
in all likelihood, I just made the gcc less broken.
2. Coreutils (ab)used the old cross-compiling infrastructure to depend on
a native version of itself. When coreutils was overwritten to be built
with fewer features, the native version it used would also be
overwritten because the binding was tight. Now it uses the much looser
`BuildPackages.coreutils` which is just fine as a richer build dep
doesn't cause any problems and avoids a rebuild.
So, in conclusion I'd say the conservatism payed off. Onward to actually
raking the muck in the next PR!
[1]: https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
|
| |
|
|
| |
Fixes #21649
|
| |
|
|
|
|
| |
I broke this in the cleanups I did in 171c7f0, the gcc inside the bootstrap
tarball is not getting built with the correct --with-fpu, --with-float
etc. options.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Do this because I cannot figure out how to refer to `glibc.static`
inside busybox when cross building in a manner that works.
|
| |
|
|
|
| |
E.g. we had `arch = "arm"` in the former and `arch = "armv6"` in the
latter. Try to have some more consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- cloog, ppl, cloogppl aren't used by recent GCCs. Kill references to them.
- Use correct versions of isl, as the current GCC depends
on non-default versions of them.
- Also clarify isl dynamic libraries are needed in cross
builds, but not in native builds
- Since aeb3d8c (bzip2: fix cross build on mingw by using autoconf patch),
it seems that the bzip2 binary depends on libbz2 when cross compiling.
So copy libbz2 into the bootstrap tarball as well.
- Curl isn't used in the bootstrap tools since e6f61b4cf3388.
|
| |
|
|
|
|
|
|
|
|
|
| |
Our coreutils now uses single-binary-build mode where, by default,
simple shebang scripts are used for all the binaries. That doesn't work
e.g. with the Linux unpacker which only handles standard binaries and
symlinks. Let's use the symlinked mode instead for boostrapping.
This does NOT change any stdenv hashes.
I only tested the case most important to me:
$ nix-build pkgs/top-level/release.nix -A stdenvBootstrapTools.x86_64-linux.test
|
| | |
|
| |\
| |
| |
| |
| | |
Beware that stdenv doesn't build. It seems something more will be needed
than just resolution of merge conflicts.
|
| | |
| |
| |
| | |
nixpkgs repository.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\|
| |
| |
| | |
Many non-conflict problems weren't (fully) resolved in this commit yet.
|
| | |
| |
| |
| | |
This reverts commit 5e3fe3916a1aef6c2b441d9009f8a8d7f14030d6.
|
| | |
| |
| |
| |
| |
| |
| | |
Several places in the tree associate the ARMv7 system
with the beaglebone platform. Change them to point to
armv7l-hf-multiplatform as it supports several boards (including the
beaglebone as well)
|
| | | |
|