cctools: 973.0.1 -> 1010.6 #307880
Draft
cctools: 973.0.1 -> 1010.6 #307880
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
6.topic: python
6.topic: haskell
6.topic: qt/kde
6.topic: ruby
6.topic: vim
6.topic: stdenv
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This changes ld-wrapper to use a temporary file for the response file passed to ld instead of using process substitution. ld64 does not handle long command-lines when reading from the response file, which defeats the point of using a response file to handle long command-lines. cctools-port was patched to work around this, but nixpkgs is now using Apple’s source release directly instead of the port. Since it’s preferable not to patch Apple’s release heavily (to reduce the difficulty of updating to new versions and to match upstream’s behavior), use the approach that was adopted in cc-wrapper to work around issues with response files in newer versions of clang. Related PRs (cctools-port): - NixOS#213831 - tpoechtrager/cctools-port#132 Related PRs (cc-wrapper): - NixOS#245282 - NixOS#258608
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will update ad hoc signatures after they perform their modifications. The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful. In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature. It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one. Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin. Fixes NixOS#208951.
Darwin and its bootstrap tools both use LLVM 16, which is sufficient for arm64e support in LLVM. Thsi change removes an unnecessary LLVM 13 build from the stdenv bootstrap.
- Use postLinkSignHook and wrap `strip` and `install_name_tool` until the updated cctools and ld64 can be built, which handles ad hoc signatures automatically as long as they are linker-signed; - Drop postLinkSignHook from binutils once it is no longer needed; - Move the minimal Python 3 with scproxy build to stage 1; - Combine multi-part stage 2 into a single stage; - Always use response files now that the bootstrap tools linker is a new enough version to support them; - Use superDarwin.binutils-unwrapped even in stage0 because it just symlinks things into place. This simplifies to bootstrap; - Drop use of cctools-llvm because the logic was moved to darwin.binutils-unwrapped, and cctools-llvm is now an alias for that; - Prevent curl and GNU binutils from being used in the bootstrap; and - Build libunwind along with libc++ and propagate it to the final overlay. It will eventually become the default libunwind on Darwin.
The bootstrap clang reports its version as “boot”, which results in unwanted test failures when the `-Wnull-pointer-subtraction` workaround is disabled.
Using python3Minimal avoids infinite recursions in the stdenv bootstrap on x86_64-darwin when building Python with configd support.
Since version 819.6, ld64 no longer supports static archives embedded in static archives.
The source-based SDK uses a newer version of AvailabilityMacros.h, which defines various newer SDK availability macros. They are correctly defined to `UNAVAILABLE_ATTRIBUTE`, but git only checks whether they exist, which results in its misdetecting the 10.12 SDK as a 10.13 (or newer) SDK.
The source-based SDK uses a newer version of AvailabilityMacros.h, which defines various newer SDK availability macros. They are correctly defined to `UNAVAILABLE_ATTRIBUTE`, but git only checks whether they exist, which results in its misdetecting the 10.12 SDK as a 10.13 (or newer) SDK.
As of NixOS#265102, x86_64-darwin no longer uses the open-source CF release. Since there is no longer a need to switch between implementations, and the hook causes problems with cross-compilation (see NixOS#278348), drop the hook and make both darwin.CF an alias for darwin.apple_sdk.frameworks.CoreFoundation.
x86_64-darwin no longer uses the source-based CF, making this setup hook unnecessary and harmful since it can break builds with the updated ld64.
After the CoreFoundation hook was dropped, bacula requires the following changes to build on Darwin: * Ensure bacula links CoreFoundation. Override incorrectly failing `configure` tests and add gettext as a build input. Even if those tests pass, bacula only links CoreFoundation when it finds libintl. * Add Kerberos framework. Required to build on x86_64-darwin.
- Make util-linux conditional in wine-staging due to `uuid.h` conflicts; - Remove `lib.overrideDerivation`, allowing wine-staging overrides; - Use `overrideSDK` to build with the 11.0 SDK with a 10.7 deployment target, matching the deployment target of the unofficial Mac packages; - Drop all Darwin-related patches. They’re not needed with the 11.0 SDK; - Switch to conditionally using `badPlatforms` instead of using a mix of `broken` and filtering Darwin from `meta.platforms`; and - Remove unnecessary rpath references to Darwin frameworks.
12 tasks
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
This PR updates cctools and ld64. It also fixes related breakage. It is currently set to draft until 24.05 is released. I will be rebasing weekly against staging, resolving any merge conflicts then. Before updating the ld64 branch, I build my configs and the Darwin channel blockers to confirm no regressions.
The following notes are copied from https://discourse.nixos.org/t/darwin-updates-news/42249/10.
Packaging Changes
Note: ld-prime is will not be packaged because it is not currently included in the source releases. While I think it’s unlikely, ld-prime will be added separately as a new package should the source be released.
New Features
Breaking Changes
-rpathwhen merging Mach-O object files fails.-qand-Qflags are supported to control whether it calls GNU as or the clang assembler (matching the upstream behavior ofas).stripandinstall_name_toolare no longer wrapped withsigtool. If you are modifying linker-signed binaries, which should be the typical case, they will update the signatures automatically. If you are manually invokingcodesign, you will need to update the signatures manually after runningstriporinstall_name_tool.stdenv updates
darwin.bintools changes
darwin.bintools changes
llvm_cmdsandcctools_cmdsrespectively). All binaries are symlinked to their traditional names (e.g., llvm-strip is symlinked to strip).isCCToolsand notisLLVMbecause it does not use lld by default. Maybe that could change with lld 18, but I’m doubtful.Resolved Issues
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.