Also fix numberous bugs, such as:
- Not getting confused on more flags taking file arguments.
- Ensuring children reexport their children, but the original
binary/library doesn't.
- Not spawning children when it turns out we just dynamically link
under the threshold but our total number of inputs exceeeds it.
- Children were always named `libunnamed-*`, when that name was
supposed to be the last resort only.
ld-wrapper's own RPATH check hardcodes `.so`, but darwin uses `.dylib`
*and* (in practice due to lousy build systems) `.so`. We don't care
however because we never inject `--rpath` like that in practice on
Darwin. Hopefully someday we won't on linux either.
Source master rebase of my [PR #34].
Eventually, we might consider doing something for GNU binutils too, in
order that we switch (the normal) ld-wrapper to always use this to
leverage ld to resolve libraries, rather than faking it in bash.
[PR #34]: https://github.com/tpoechtrager/cctools-port/pull/34
Since at least d7bddc27b2, we've had a
situation where one should depend on:
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables,
regardless of the host platform, at run time.
and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:
- `binutils` is indeed unconditionally GNU Binutils
- `binutils-raw`, which previously served that role, is gone.
so that the correct usage will be enforced going forward and everything
is simple.
N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
Since GHC is a cross compiler, it's perfectly possible to make haskell
binaries on platforms without GHCs. `windows ++ unix` seems good enough
for now.
Also don't default `hydraPlatforms` to `platforms`. The former must be a
list of systems (strings), but the latter is a list of systems or
patterns.
Otherwise obscure cross-compilations are hampered. `all` breaks all but
the initial derivation (which we can't even write yet) in an open world
setting however, so we really shouldn't have it.
Instead of intersecting system strings, we filter with the sort of
patterns used in `meta.platforms`.
Indicating this change `forTheseSystems` has been renamed to
`forMatchingSystems`, since the given list is now patterns to match, and
not the systems themselves. [Just as with `meta.platforms`, systems
strings are also supported for backwards compatibility.]
This is more flexible, and makes the `forMatchingSystems` and
packagePlatforms` cases more analogous.
I noticed LLVM accepts `ios` as its own OS in platform triples; a
recent change as far as I know. I see it also accepts `macos*` for macOS
(formerly OS X). If it's now customary to distinguish iOS like so
(rather than guessing from the aarch, lets add both so our OSes are
still disjoint, and make Darwin a family instead.
But changing the config everywhere would probably be a mass rebuild, and
I'm not sure how well other software supports OSes besides "darwin", so
I'm keeping that the default name for macOS for now.
First, we need check against the host platform, not the build platform.
That's simple enough.
Second, we move away from exahustive finite case analysis (i.e.
exhaustively listing all platforms the package builds on). That only
work in a closed-world setting, where we know all platforms we might
build one. But with cross compilation, we may be building for arbitrary
platforms, So we need fancier filters. This is the closed world to open
world change.
The solution is instead of having a list of systems (strings in the form
"foo-bar"), we have a list of of systems or "patterns", i.e. attributes
that partially match the output of the parsers in `lib.systems.parse`.
The "check meta" logic treats the systems strings as an exact whitelist
just as before, but treats the patterns as a fuzzy whitelist,
intersecting the actual `hostPlatform` with the pattern and then
checking for equality. (This is done using `matchAttrs`).
The default convenience lists for `meta.platforms` are now changed to be
lists of patterns (usually a single pattern) in
`lib/systems/for-meta.nix` for maximum flexibility under this new
system.
Fixes#30902
Negative reasoning like `allBut` is a bad idea with an open world of
platforms. Concretely, if we add a new, quite different sort of
platform, existing packages with `allBut` will claim they work on it
even though they probably won't.
These shouldn't respond to targetPlatform, but previously did. The
reason is somewhat complex: they would rely on the sources of gcc and
binutils, respectively, which *do* depend on the target platform.
Obviously the source is the same in all cases, but when those packages
are no longer preserved from bootstrapping stages their `src` attributes
use a different fetchurl resulting in a changed hash.
I need some module system types here so I can next fix meta-checks for
derivations. I'd like to use a "proper" record type here, but submodule
types seem overkill so holding off with ad-hoc stuff for now. In
practice, all I need for the next step are the `.check` functions so
this is good, especially as the submodule check function is shallow,
saving full inductive type-checking for a later step.
We still ensure the old and new ones start, respectfully, with `a/` and
`b/`. Use with `stripLen` to ensure tha the old `a/` and `/b` are gone
if a new prefix is added.
In anticipation of what I outline in #33599, I only simplify exactly those
`doCheck`s which are equal to `hostPlatform != buildPlatform`. I also stick a
comment next to them so I can grep for them later.
I hope this will be a temporary measure. If there is consensus around
issue #33599, then we can follow an explicit `dontCheck`, but default to
not checking during cross builds when none is given.
John Ericson