Darwin systems need to be able to find CoreFoundation headers as well as
libc headers. Somehow, gcc doesn't accept any "framework" parameters
that would normally be used to include CoreFoundation in this
situation.
HACK: Instead, this adds a derivation that combines the two. The result
works but probably not a good long term solution.
ALTERNATIVES: Maybe sending patches in to GCC to allow
"native-system-framework" configure flag to get this found.
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.
This currently only produces a static library, but is a start :) soon we
might be able to incorporate it into our stdenv, but we need to get the
build system to produce a proper .framework first.
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.
The AVFoundation framework uses a relative path that presumes that
CoreGraphics is a child framework of ApplicationServices. It is not in
the 10.9 SDK.
This patch makes it one by tweaking the framework derivation generator
with special support to address this problem.
The `otool` binary is provided by the `cctools` package (and `binutils`)
on darwin, which is properly packaged and compiled from source.
This old standalone `otool` was simply a symlink to `/usr/bin/otool`,
which notably depended on the user having already installed the Command
Line Tools via XCode, and would fail dependent builds if they hadn't.
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.
