Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
- Give cctools a dev output for the headers
- Update Libsystem to grab the headers from that dev output
- Don't include the headers in Darwin binutils, just as GNU Binutils no
longer does.
This includes adding a new xcbuild-based libutil build to test the waters a bit there.
We'll need to get xcbuild into the stdenv bootstrap before we can make the main build,
but it's nice to see that it can work.
This requires some small changes in the stdenv, then working around the
weird choice LLVM made to hardcode @rpath in its install name, and then
lets us remove a ton of annoying workaround hacks in many of our Go
packages. With any luck this will mean less hackery going forward.
The main changes are in libSystem, which lost the coretls component in 10.13
and some hardening changes that quietly crash any program that uses %n in
a non-constant format string, so we've needed to patch a lot of programs that
use gnulib.
This sort of thing is going to get revamped to be less hackish soon but
for now I want it to work. In this particular case, libc++ 4 (and maybe
earlier) gets very upset if we're imprecise about our const markers, and
I guess libauto was careless. This fixes it (PtrPtrMap) to be correct.
This wasn't being used and it was causing an error when evaluating:
error: attribute ‘CoreOSMakefiles’ missing, at /Users/mbauer/Projects/nixpkgs2/pkgs/os-specific/darwin/apple-source-releases/default.nix:140:71
pkill isn't building because of some missing headers:
- xpc/xpc.h
- os/base_private.h
- _simple.h
They are all available somewhere but not set up correctly in the Darwin
stdenv.
TODO: add pkill back in!
This actually has no effect but it bugged me to keep seeing an old version
in the package names :) and since we're making a bunch of stdenv changes
at once, I might as well.
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
It's a long build and generally painful to split into smaller commits,
so I apologize for lumping many changes into one commit but this is far
easier.
There are still several outdated parts of the darwin stdenv but these
changes should bring us closer to the goal.
Fixes#18461
Revert a revert of a merge that shouldn't have been in master but was intentionally in staging.
Next time I'll do this right after the revert instead of so far down the line...
This reverts commit 9adad8612b.
We don't actually need the private headers and the private qos.h was
overwriting the public one, causing weird issues downstream (especially
with Swift's CoreFoundation)
I can't submit this in smaller units because the various components all
depend on one another during the stdenv bootstrap, so I think this is
the smallest sensible change I can make.
I also removed the symbol-hiding shenanigans in Libsystem. It might mess
up compatibility with 10.9 but I don't really want to support the added
complexity and I see little evidence of anyone else wanting to support
it. If someone cares, we might be able to revive compatibility, but for
now it'll stay like this.
This also changes the versioning scheme to be in more "human-meaningful"
terms, so instead of the internal release numbers we talk about 10.10.5
or 10.9.5.
adv_cmds archive actually contains BSDmakefile, not BSDMakefile. While
that probably doesn't matter in default installations, it does matter
for case-sensitive filesystems.
`nix-env -qaP -A pkgs.darwin`
pkgs.darwin.libutil:
Commented-out because the package definition doesn't exist. The source
doesn't even provide a Makefile...
pkgs.darwin.objc4_pure:
Commented-out because the package is broken and referencing unknown
applefetchsource and libc_old names. It doesn't seem to be used by any
other packages too.