This can result in swift-corefoundation being included even when a
derivation uses `apple_sdk_11_0.stdenv` directly, which may result in
hard to debug compiler errors (unless you just happen to know cryptic
compiler errors means the 10.12 and 11.0 SDKs have been mixed).
Clang 16 makes implicit declarations an error by default. The headers
are available, so include them.
`getline` was renamed to `get_line` to avoid a name clash. `util.h`
includes `stdio.h`, which defines `getline`.
cctools-llvm is a replacement for cctools that replaces as much of cctools with equivalents from LLVM that it can reasonably do. This was motivated by wanting to reduce dependencies on cctools, which are updated infrequently by upstream.
To provide a motivating example, the version of `strip` included in cctools cannot properly strip the archives in compiler-rt in LLVM 15. Paths are left to bootstrap tools, resulting in failed requisites checks in the final stdenv build. Since `strip` needs replaced, the opportunity was taken to replace other provided they are functional replacements.
Note: This has to be done in cctools (or some equivalent) because some derivations (noteably LLVM) use the bintools of the stdenv directly instead of going through the wrapper.
The following tools from LLVM are not used in this derivation:
* LLD - not fully compatible with ld64 yet and potentially too big of a change;
* libtool - not a drop-in replacement yet because it does not support linker passthrough, which is needed by xcbuild;
* lipo - crashes when running the LLVM test suite;
* install_name_tool - fails when trying to build swift-corefoundation; and.
* randlib - not completely a drop-in replacement, so leaving it out for now.
If other incompatabilities are found, the tools can be reverted or made conditional. For example, cctools `strip` is preferred on older versions of LLVM (which lack the compiler-rt issue) or when cctools itself is a new enough version because `llvm-strip` on LLVM 11 produces files that older verions of `codesign_allocate` cannot process correctly.
One final caveat/note: Some tools are not duplicated or linked from cctools-port. The names of the tools and which ones were linked was determined based on what is provided upstream in Xcode and is installed on macOS system.
This probably hasn’t built for a while. Apple is redirecting to GitHub,
which results in different hashes for cctools and ld64. While I’m fixing
the hashes, I also updated the sources to use `fetchFromGitHub`.
The 10.12 SDK uses `xar`, which depends on Python indirectly, which
depends on configd by default. This causes an infinite recuresion when
building configd because it needs SDK headers to build with clang 16.
Fix the infinite recursion by disabling Python support in libxml2 when
building the SDK, and use a minimal Python in the SDK build itself.
This was found while working on the Darwin stdenv rework. This change
allows rewrite-tbd to use the provided Makefile instead of depending on
cmake and pkg-config.
Co-authored-by: Weijia Wang <9713184+wegank@users.noreply.github.com>
Closes#230870. Thanks to @eliasnaur for the test case and for rasining
awareness and to @veprbl for the work done on #111385.
This takes a slightly different approach from those two PRs. The hook is
set unconditionally. The stdenv bootstrap doesn’t really need CF at all,
so setting the hook is harmless. This simplifies things.
Clang 15 does not like the fake xpc headers. Use the real ones instead.
Doing this no longer causes an infinite recursion because xnu now
depends on python3Minimal, which does not include configd support.
Contrarily to the other frameworks, System framework's TBD file
is a symlink pointing to `${MacOSX-SDK}/usr/lib/libSystem.B.tbd`.
This produces an error when using the framework, as:
1. The original file is not copied into the output directory
2. Even if it was copied, the relative path wouldn't match
Resulting in the symlink being broken and the linker failing when
trying to link `-framework System`.
The fix applied consists in replacing the symbolic link with the
actual file, as this is easier than fixing the link and doesn't
seem to produce any side effects.
This fixes build failures caused by LibreSSL 3.4 being marked insecure
and allows it to be dropped from nixpkgs. Unbound is already not built
on aarch64-darwin, and it is not bundled with newer source releases.
Packages that require Unbound should depend on `unbound` from nixpkgs
instead of getting it indirectly from `darwin.network_cmds`.
* raycast: init at 1.48.9, change github release url to internet archive url
* raycast: adding documentation explaining the reason we are using Internet Archive URL
* raycast: add lovesegfault to maintainers
Co-authored-by: Bernardo Meurer <bernardo@meurer.org>
The SDK was missing SDKSettings files. This is usually not a problem for
Nix builds, because we generate our own fake SDK structure when
necessary (in xcbuild), but not having these files blocks using the
upstream Apple SDK in tooling such as gen-frameworks.py.
The motivation behind this is to alleviate the problem
described in https://github.com/NixOS/nixpkgs/issues/41340.
I'm not sure if this completely fixes the problem, but it
eliminates one more area where we can exceed command line
length limits.
This is essentially the same change as in #112449,
except for `ld-wrapper.sh` instead of `cc-wrapper.sh`.
However, that change alone was not enough; on macOS the
`ld` provided by `darwin.cctools` fails if you use process
substitution to generate the response file, so I put up a
PR to fix that:
https://github.com/tpoechtrager/cctools-port/pull/131
… and I included a patch referencing that fix so that the
new `ld-wrapper` still works on macOS.
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
7abd144913 switched the source releases to
pull from GitHub. This resulted in the IOUSBFamily installation failing,
as the extracted directory's name changed from `IOUSBFamily-630.4.5` to
`IOUSBFamily-IOUSBFamily-630.4.5`. This didn't occur for any other frameworks
because we used wildcards for copying them already.
What dtrace needs from the CoreSymbolication private framework on Darwin
is provided in Nixpkgs by two different packages, but both of their full
attribute paths end in CoreSymbolication.
This commit therefore does two things:
- adds the second CoreSymbolication package to dtrace's dependencies;
and
- adds an alias for the second CoreSymbolication package to avoid
having to explicitly name or rename it when calling the dtrace
package in the existing contexts.
This reverts commit 511f21df7c.
In apple_sdk_11_0, the xpc package contains only headers that are
already part of libsystem, so this change did nothing.
For Swift and `-fmodules`, this actually caused an error, because
there was now a duplicate module in the search path.
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.
