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`.
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`.
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>
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.
