For reasons explained in the commit contents, in order to build the
native gnat package for x86_64-darwin, the native gnatboot package for
x86_64-darwin must have access to both the Clang integrated assembler
and the cctools GNU assembler for that platform. This commit creates a
package with both of those assemblers that x86_64-darwin gnatboot can
then be wrapped with.
This removes the need for the yabai-load-sa script on x86_64-darwin, the
scripting addition can now simply be installed/launched with
`yabai --load-sa`.
Some packages like `bazel-watcher` seems to have broken after
9dc3b14859
Where `xpc` was removed from `IOSurface` dependencies.
`CoreServices` were pulling `xpc` via `IOSurface` and so `Security`
didn't break. Now explicit dependency on `xpc` is needed to avoid
errors like
```
In file included from __main__/external/com_github_fsnotify_fsevents/go_1_10_after.go:6:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:29:
In file included from /nix/store/2k3mdkl9jvwwzpbfaqhchfiqjq64046b-apple-framework-CoreServices-11.0.0/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43:
In file included from /nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/Security.h:87:
/nix/store/dg51rm1bapffbqvn46bh43km4dhcsy9p-apple-framework-Security-11.0.0/Library/Frameworks/Security.framework/Headers/SecCode.h:35:10: fatal error: 'xpc/xpc.h' file not found
^~~~~~~~~~~
```
Should help with https://github.com/NixOS/nixpkgs/pull/203519
Done with the help of https://github.com/Mindavi/nixpkgs-mark-broken
Tool is still WIP but this is one of the first results.
I manually audited the results and removed some results that were not valid.
Note that some of these packages maybe should have more constrained platforms set
instead of broken set, but I think not being perfectly correct is better than
just keep trying to build all these things and never succeeding.
Some observations:
- Some darwin builds require XCode tools
- aarch64-linux builds sometimes suffer from using gcc9
- gcc9 is getting older and misses some new libraries/features
- Sometimes tools try to do system detection or expect some explicit settings for
platforms that are not x86_64-linux
Co-authored-by: Robin Gloster <mail@glob.in>
stdenv: print message if structuredAttrs is enabled
stdenv: add _append
reduces the chance of a user doing it wrong
fix nix develop issue
output hooks don't work yet in nix develop though
making $outputs be the same on non-structuredAttrs and structuredAttrs
is too much trouble.
lets instead make a function that gets the output names
reading environment file '/nix/store/2x7m69a2sm2kh0r6v0q5s9z1dh41m4xf-xz-5.2.5-env-bin'
nix: src/nix/develop.cc:299: std::string Common::makeRcScript(nix::ref<nix::Store>, const BuildEnvironment&, const Path&): Assertion `outputs != buildEnvironment.vars.end()' failed.
use a function to get all output names instead of using $outputs
copy env functionality from https://github.com/NixOS/nixpkgs/pull/76732/commits
Stdenv on aarch64-darwin pulls in (bootstrap-stage4) objc4, unlike
x86_64. However derivations that otherwise depend on objc4 would use a
a different objc4 derivation on top of the final stdenv.
Because this library defines an LLVM module, having multiple instances
of it in the import path will interfere with builds.
In b060076e21 ("cc-wrapper: broaden explicit libc++abi linking for
LLVM stdenv"), all packages started to be linked with -lc++abi. When
cross compiling, the libcxxabi path seemingly needs to be passed to the
the libtapi derivation; it won't pick it up on its own (perhaps because
of the bootstrapping?).
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
- Use the 11.0 SDK instead of the 10.12 one on x86_64-darwin;
- Use `NIX_CFLAGS_COMPILE` and `NIX_LDFLAGS` to pass flags to the
compiler instead of patching the Xcode project files; and
- Use xcbuild to build the project.
