Tracking issue for Darwin stdenv LLVM update #234710
Labels
2.status: work-in-progress
This PR isn't done
6.topic: darwin
Running or building packages on Darwin
Comments
This was referenced May 29, 2023
Closed
|
Things are looking pretty good, but alas I have another round of PRs that I’ll be opening up soon. Some of them are required for the stdenv rework while others are required for the actual bump. My current thinking is to bump to LLVM 16 because that will match what Apple will ship with Xcode 15. However, that requires fixing a number of packages to build with clang 16, which is more strict about function prototypes and some other stuff. Those are the additional PRs I will be submitting. The only potential blocker with LLVM 16 is clang 16 sometimes fails with a bad file descriptor error. I think it has to do with the use of process substitution to create the response file used to pass arguments to |
|
@reckenrode it's a long shot, but is NixOS/nix#6516 related to your bad file descriptor error? Only relevant if you're testing in CA mode. |
Unfortunately, probably not. CA mode doesn’t even work on aarch64-darwin. #178280 might be related. I haven’t really dug into it too deeply because I can restart the build when it happens. That’s not good for a final PR, but it lets me get everything else building before I try to dig into root causes. The big difference for me compared to NixOS/nix#6516 is it’s always the same FD (63). Bash’s process substitution starts counting at 63, which is why I believe cc-wrapper is involved. The question is why the FD doesn’t live long enough and what is trying to read it once it’s gone. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
FliegendeWurst
added
6.topic: darwin
12 tasks
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/macos-system-integrity-protection-and-dy-dl-library-path/31729/5 |
jacg
added a commit
to jacg/nain4
that referenced
this issue
Aug 17, 2023
There were two main problems
1. Dynamic linking on macOS requires some extra hoop-jumping:
```cmake
if(APPLE)
target_link_options(nain4-tests PRIVATE -undefined dynamic_lookup)
endif()
```
2. There was a clash of libc++ versions between clang 16 and the
dependencies pulled in by Qt and Geant4. This caused very mysterious
segfaults before main was entered on pretty much any executable.
We got around this by overriding the libc++ version used by clang 16
on Darwin. (The Linux version had no such problems).
An [upstream fix](NixOS/nixpkgs#234710) is
in the works. Once that lands, we can remove our hack.
Now that all this has been fixed, GHA failures on macOS are no longer
allowed.
We need to bump the tag in the client-side fetch-content test, which
will continue to fail until we push the corresponding tag to this merge
commit.
This was referenced Sep 6, 2023
This was referenced Oct 5, 2023
|
Full report at https://gist.github.com/tobim/5ce3c6d6f49f29ac43b3ad76b96bd1e4. Problematic dependencies
Generated by eval-report |
|
Thanks for the report. It’s heartening that the most severe offenders are fixed already on staging or have open PRs with fixes. |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
|
The LLVM update has been merged into master. |
12 tasks
13 tasks
emilytrau
added a commit
to emilytrau/nixpkgs
that referenced
this issue
Nov 20, 2023
Regression from darwin stdenv bump (NixOS#234710)
13 tasks
13 tasks
boltzmannrain
added a commit
to boltzmannrain/nixpkgs
that referenced
this issue
Nov 23, 2023
Fixing `bazel_5` after NixOS#234710 Error example https://hydra.nixos.org/build/241240612/nixlog/1 ``` external/com_google_absl/absl/meta/type_traits.h:560:8: error: builtin __has_trivial_assign is deprecated; use __is_trivially_assignable instead [-Werror,-Wdeprecated-builtins] (__has_trivial_assign(ExtentsRemoved) || !kIsCopyOrMoveAssignable) && ``` Similar to NixOS#269297, and remaining `bazel_4` is WIP for another PR
13 tasks
boltzmannrain
added a commit
to boltzmannrain/nixpkgs
that referenced
this issue
Nov 23, 2023
Fixing `bazel_4` after NixOS#234710 Error example https://hydra.nixos.org/build/241174862/nixlog/1 ``` Execution platform: //:default_host_platform third_party/zlib/gzwrite.c:89:20: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] writ = write(state->fd, strm->next_in, put); ^ ``` Similar to NixOS#269481 and NixOS#269297
13 tasks
github-actions bot
pushed a commit
that referenced
this issue
Nov 30, 2023
Fixing `bazel_5` after #234710 Error example https://hydra.nixos.org/build/241240612/nixlog/1 ``` external/com_google_absl/absl/meta/type_traits.h:560:8: error: builtin __has_trivial_assign is deprecated; use __is_trivially_assignable instead [-Werror,-Wdeprecated-builtins] (__has_trivial_assign(ExtentsRemoved) || !kIsCopyOrMoveAssignable) && ``` Similar to #269297, and remaining `bazel_4` is WIP for another PR (cherry picked from commit 781538c)
github-actions bot
pushed a commit
that referenced
this issue
Nov 30, 2023
Fixing `bazel_4` after #234710 Error example https://hydra.nixos.org/build/241174862/nixlog/1 ``` Execution platform: //:default_host_platform third_party/zlib/gzwrite.c:89:20: error: call to undeclared function 'write'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] writ = write(state->fd, strm->next_in, put); ^ ``` Similar to #269481 and #269297 (cherry picked from commit 746e394)
zhaofengli
added a commit
to zhaofengli/nixpkgs
that referenced
this issue
Dec 3, 2023
Fallout from NixOS#234710.
13 tasks
13 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a tracking issue to update the version of LLVM in the Darwin stdenv. I am breaking this out of #229786 into a tracking issue so I can submit and track PRs for the work I have done while I work through the ofborg outPath check failures. The longer I wait, the greater the risk of merge conflicts.
This issue was prompted by #229210 because the 13.3 SDK requires a newer Clang than the Darwin stdenv provides currently. To facilitate easier LLVM updates in the future, I have created a PR to rework the Darwin stdenv to decouple it from the versions of programs included in the bootstrap tools. I have also reworked it to follow the patterns used in the Linux stdenv.
See the comments in PR explaining the rework. My hope is it will make maintenance easier and more approachable. It should also make experimentation a little safer due to evaluation-time failures that stop “obvious” mistakes from turning into wasted build time. Possible areas for future exploration: removing ICU (in favor of the icu in nixpkgs) and libiconv (in favor of libiconvReal), using LTO during bootstrap.
LLVM Update PR
Previous PR
Rework Prerequisite PRs
These PRs are required for the stdenv bump. They reflect breakage due to stricter checks by clang or as required by the stdenv rework. Most of these PRs are required for clang 15. Some are required for clang 16. They should work with clang 11.
This PR was dropped.
LLVM Bump Prerequisite PRs
These PRs are not required for the rework, but they are required prior to the bump because it prevents the bootstrap from completing with clang 16.
Related PRs
These fail to build due to the changes or pertain to some other issue uncovered while working on the bump. They are not required for the bump, but they’ll make it go more smoothly after it is merged.
NIX_CC_NO_RESPONSE_FILElogic #245640These PRs were dropped.
These are Darwin sandbox-related fixes. They’re not strictly necessary, but they allow Darwin users to build more things with the sandbox enabled.
This fix is related to running the store on case-sensitive APFS. It’s the first thing that has broken for me. Most case sensitivity issues during builds are due to
/tmpbeing insensitive.This issue is SIP-related, which shouldn’t affect most users.
The text was updated successfully, but these errors were encountered: