The current hook specifies the path to the framework library, but
nixpkgs does not actually provide the library when linking against the
system framework. It provides a text-based stub (`.tbd`) instead. ld64
will find the stub and use it, but lld will not when the full path is
specified. Both linkers work if the extension is included, so do that
for compatibility with both. This fixes using lld with CoreFoundation
(e.g., to support LTO on Darwin).
Clang 11 performs an optimization on x86_64 that is sensitive to the
presence of debug information. This results in GCC’s bootstrap failing
because it builds stage 2 with debug information and stage 3 without,
and the resulting objects do not match.
This patch uses the cctools assembler on LLVM 11 and x86_64-darwin while
using the integrated assembler on newer versions, which matches the
platform tools (Apple has uses the integrated assembler since Xcode 12).
@emilazy found a bug in #234861. Specifically, the hook is not actually
applied. e2fsprogs links against darwin.CF, but since it cannot find the
framework by rpath, it crashes.
Since the hook should always be used, it is copied directly to
`nix-support/setup-hook` instead of providing it as an attribute. This
preserves dropping the hook in the cross-compilation case while
providing it for everything else that needs it.
To avoid further churn and due to the complexity of building the stdenv
with the hook active, this change required the stdenv rework.
swift-corelibs uses libcurl to implement `NSURLSession` in Foundation
via the symbols exported by CF. Foundation is not build on Darwin, and
these symbols are not exported by the system CoreFoundation.
By not linking against libcurl, this breaks a cycle between CF and
libcurl. That should allow libcurl to drop the patch disabling
linking against the SystemConfiguration and restore NAT64 support.
Unfortunately, the Darwin stdenv bootstrap still needs to build
dependencies that use `fetchFromGitHub`. While it can drop curl from the
final stdenv, it still needs to use it during the stdenv bootstrap.
Upstream swift-corelibs links against icu on Linux, so it is not
necessarily tied to the version of ICU provided by Apple for Darwin.
swift-corelibs and qtwebkit are the only two packages that link against
darwin.ICU. Switching to the nixpkgs icu will allow the Darwin-specific
package to be deprecated and removed eventually.
Switching the build system to cmake makes it easier to make changes to
the build (particularly which dependencies to link). It also removes a
lot of manual build steps and fixes the issue identified by @emilazy in
NixOS#238791.
Fixes NixOS#238791.
This is an additional fix for clang 16, which fails due to an undeclared
symbol. Adding `_DNS_SD_LIBDISPATCH` makes the symbol visible in
`dns_sd.h`, allowing the build to complete successfully.
after communicating with the Raycast team (thanks Sorin), they added API for
1. Getting the latest version of Raycast via REST endpoint https://releases.raycast.com/releases/latest
2. Versioned download in the format of https://releases.raycast.com/releases/<version>/download
This update deprecates download via internet archive and switches to official download API
This was not caught when cctools-llvm was added. The parens are
necessary to make sure this evaluates correctly when LLVM is new enough
to provide a compatible `otool`.
A number of headers in Libc are being vendored from other packages.
Instead of copying them from an earlier Libc, Libsystem now sources them
from their respective packages (see below). This allows Libc_old to be
dropped and avoids any potential clashes when building Libsystem.
libmalloc:
* malloc/malloc.h
libplatform:
* setjmp.h
* ucontext.h
* libkern/OSAtomic.h
* libkern/OSCacheControl.h
libpthread:
* pthread*.h
* sched.h
* spawn.h
syslog (vendored because only one file is needed):
* asl.h
xnu:
* spawn.h (a different one from libpthread)
* libproc.h
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.
