libtool is not really needed and it interferes with
updateAutotoolsGnuConfigScriptsHook. So remove it when
cross-compiling, but leave it in native to preserve hashes.
Based on testing this issue seems to only occur with clang_7, so
we should be able to revert this when the default llvm versions are
updated.
Fixes#66811
The only remaining use-case for cf-private are symbols that are not
available in the opensource build. This generally solved the problem
because of it's setup-hook.
CoreFoundation is included by the stdenv, moving the decision of what
version should be used there makes it possible to override it entirely
rather then prepending flags like cf-private does which can be
unreliable.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
This round is without the systemd CVE,
as we don't have binaries for that yet.
BTW, I just ignore darwin binaries these days,
as I'd have to wait for weeks for them.
The only outside-curl uses of `fetchurlBoot` left are `stdenv`
and `apple-source-releases`. The latter one can probably be removed
too, but I can't test it.
Pros:
- Aggregates all behind-the-scenes insanity in a single place.
Cons:
- At the cost of 10 more derivations (but 0 new outpaths).
This reverts commit ac682e362c.
This broke iOS building on master. Even Xcode 8.2 comes with TAPI
librarises. We need these patches to support those .tbd files.
Eventually we will move to using libtapi directly, but I have not
finished work on this right now.
Unfortunately, this will not have my changes for building cctools with
manpages. We will have to do this update at some later time.
It was removed on recent versions of macOS and these entries break
sandboxing if they don't exist.
Aborted: while setting up the build environment: getting attributes of path '/System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity': No such file or directory
xcbuild doesn’t handle dsymutil correctly. fuser.pl does not contain
debug symbols, but xcbuild doesn’t handle this like xcodebuild does.
So, just disable the debug information. We probably should do this in
more places using xcbuild, but it requires some arbitrary patching.
These just copy commands from Products/Release/. But with #52256 we
now build .dsym directories that somehow wind up in Products/Release/.
This makes things more exact by just copying the files in Products/Release/.
Lots of stuff has gotten moved around. Many security libraries have been merged
into the Security monorepo. I’ve cleared them out for now, we will
need to modify Security to build them!
This also moves some things around to more clearly separate
bootstrapping the stdenv from everything else. We want the “normal”
mode to be the non-bootstrapped version. When you ask for “Security”,
you want the actual built software, not a crippled one.
- Add TARGET_OS_OSX to darwin.libSystem. Looks like something
introduced in 10.12. TARGET_OS_MAC is only set when building for
desktop (iOS will have TARGET_OS_MAC set)
- Bump darwin.dtrace
- Bump darwin.libpthread
- Remove SmartCardServices, libsecurity*, etc.
- Install some more headers for darling.
We were previously using a dummy wrapper for dsymutil. This meant that
debug symbols were not getting generated when dsymutil was otherwise
available. This should fix that issue & provide a real dsymutil from
llvm.
Fixes#52148.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in trash-571f39.o
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in trash-571f39.o
"_OBJC_CLASS_$_NSUserDefaults", referenced from:
objc-class-ref in trash-571f39.o
objc-class-ref in HGCLIUtils-31f3b3.o
ld: symbol(s) not found for architecture x86_64