Darwin stdenv bump LLVM to 11 #126411
Darwin stdenv bump LLVM to 11 #126411
Conversation
ofborg
bot
added
10.rebuild-darwin-stdenv
|
Not specifically related but the two lines begining with the following in darwin stdenv are not required anymore. It was like the comment says a workaround for 10.11. I've tried on local and they can be safely removed. |
|
One other thing. Would you not make the PR on staging rather than master? The number of packages to be rebuilt would be quite big in this case. |
|
@happysalada, I'm targeting master rn on @LnL7's advice. It's so we have a good hydra evaluation to compare to for the custom jobset for this. IIUC once we get most of the packages building with the LLVM bump we'd change the target to staging. |
|
@LnL7, |
|
Hydra eval is running. Note that this will take a while as this jobset has very low build shares, so other builds from master and staging generally get priority. https://hydra.nixos.org/eval/1677441?compare=1677022#tabs-unfinished |
|
Shouldn't this be targeted at staging, not master? |
ofborg
bot
added
the
2.status: merge conflict
The original problem with the normalization of the filename only occurred because it was in NFC. However, when trying to fix it by `mv`ing the file to a normalization-indifferent name, I used the NFD normalized name from my file system. This means it only works on normalizing file systems. The filename must be in the original encoding and will be normalized by normalizing file systems like HFS+.
The original problem with the normalization of the filename only occurred because it was in NFC. However, when trying to fix it by `mv`ing the file to a normalization-indifferent name, I used the NFD normalized name from my file system. This means it only works on normalizing file systems. The filename must be in the original encoding and will be normalized by normalizing file systems like HFS+.
Both patches implement the same fix so they'll probably have to be removed at the same time. This avoids one of them being left behind.
Use `autoreconfHook` rather than manually running `aclocal`. Clarify removal of `version` file.
LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv, in particular, `standalone` and `withLibunwind`. Darwin stdenv needs the `standalone` flag because its `hostPlatform` set doesn't have `useLLVM` set to true. And it needs `withLibunwind` to explicitly disable including `libunwind` as a build input. We also prefix `install_name_tool` in case we're cross-compiling.
LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv, in particular, `standalone` and `withLibunwind`. Darwin stdenv needs the `standalone` flag because its `hostPlatform` set doesn't have `useLLVM` set to true. And it needs `withLibunwind` to explicitly disable including `libunwind` as a build input. We also prefix `install_name_tool` in case we're cross-compiling.
toonn
force-pushed
the
stdenv-llvm-bump
branch
from
c291f21
to
ecce906
Compare
|
Future me, is going to hate current me. But lets get this going. |
|
sorry, trying to build ripgrep on my server, to ensure something isn't fundamentally wrong all the way through to the rust toolchain. give me a few hours to do the stdenv rebuild process :( |
|
Looks like |
|
Nix won't build, probably due to this? There are also other regressions; please have a look at staging-next #148396 (comment) |
|
Oh that was the upgrade. I wasn't aware that this was merged actually. I'm curious if other darwin people have an opinion on the nix failure on staging-next. I haven't been able to figure it out. |
|
Sounds to me like it's trying to use a method introduced in SDK 10.13 and Nixpkgs is currently on SDK 10.12? I assume Clang 11 is just louder about the error and it doesn't actually cause any problems for anyone who's not on 10.12, hence not having been noticed before? |
|
I think the availability macros in libcxx are only applicable for the system /usr/lib/libc++.dylib. I think anything built purely in nixpkgs should be able to define _LIBCPP_DISABLE_AVAILABILITY without any issues. |
Motivation for this change
This bumps the LLVM used in the Darwin stdenv to 11, building on #121055, which made the required updates to the bootstrap-tools first.
Some packages the stdenv depends on needed patching because of the LLVM update so it's likely there are many packages that require compiler flags, mostly to bring the behavior back in line with clang 7, so I'm opening this as a draft to get a hydra jobset.
I'm building
helloas a test, will report back tomorrow.