Skip to content

Tracking issue for Darwin stdenv LLVM update #234710

@reckenrode

Description

@reckenrode

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.

These 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 /tmp being insensitive.

This issue is SIP-related, which shouldn’t affect most users.

Metadata

Metadata

Assignees

No one assigned

    Labels

    6.topic: darwinRunning or building packages on Darwin
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions