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`.
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.
Use autoreconfHook instead of preConfigure autogen.sh. This avoids
getting the bad version of the gnu-config script and makes the newish
iOS triples work.
libtool is not really needed and it interferes with
updateAutotoolsGnuConfigScriptsHook. So remove it when
cross-compiling, but leave it in native to preserve hashes.
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.
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.
LTO is disabled during bootstrap to keep the bootstrap tools small and
avoid unnecessary LLVM rebuilds, but is enabled in the final stdenv
stage and should be usable by normal packages.
Source master rebase of my [PR #34].
Eventually, we might consider doing something for GNU binutils too, in
order that we switch (the normal) ld-wrapper to always use this to
leverage ld to resolve libraries, rather than faking it in bash.
[PR #34]: https://github.com/tpoechtrager/cctools-port/pull/34
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
- Give cctools a dev output for the headers
- Update Libsystem to grab the headers from that dev output
- Don't include the headers in Darwin binutils, just as GNU Binutils no
longer does.
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
We want platform triple prefixes and suffixes on derivation names to
be used consistently. The ideom this commit strives for is
- suffix means build != host, i.e. cross *built* packages. This is
already done.
- prefix means build != target, i.e. cross tools. This matches the
tradition of such binaries themselves being prefixed to disambiguate.]
Binutils and cctools, as build tools, now use the latter
