-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[backport: 20.09] darwin (Big Sur): tbd based stdenv #105799
[backport: 20.09] darwin (Big Sur): tbd based stdenv #105799
Conversation
I think there's enough value in having a stable branch which can be pinned by projects and have those projects still be usable on Big Sur to justify this backport. |
We usually don't backport big stdenv changes like this. However, since Big Sur is pretty much broken without it, I think it's probably a good idea in this case. |
I would definitively like to backport the fixes, we can test for regressions with a wip jobset to make sure nothing important was missed. However I think it would be best to wait until bootstrapping and some of the missing stubs are sorted out. |
Agreed, Big Sur breakage is too big a deal to not backport IMO |
If someone is able to verify that there's no regressions, I'm fine with merging this. But it should target |
This new version has tapi support, which is needed to build the new stubs based libSystem, etc. and Big Sur support. You can verify the provenance of these yourself by checking Hydra here: https://hydra.nixos.org/build/128192471
Adapted from main expression for clang 7.
Build the llvm support libraries (libcxx, libcxxabi) from scratch without using the existing llvm libraries. This is the same spirit and similar implementation as the "useLLVM" bootstrap in llvm package sets. Critically it avoids having libcxxabi provided by the cc-wrapper when building libcxx, which otherwise results in two libcxxabi instances. $ otool -L /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib: /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.1.0.dylib (compatibility version 1.0.0, current version 1.0.0) /nix/store/gmpwk5fyp3iasppqrrdpswxvid6kcp8r-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0) /nix/store/3hn7azynqgp2pm5gpdg45gpq0ia72skg-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0) /nix/store/1nq94scbxs6bk7pimqhvz76q6cfmbv97-Libsystem-osx-10.12.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) Additionally move some utilities (clang, binutils, coreutils, gnugrep) to the stage layers so they can be replaced before the final stdenv. This should cause most of stage4 to be built from the toolchain assembled as of stage3 instead of the bootstrap toolchain.
Exposed by the tbd stubs which contains fat libraries. The previously used proxy libraries were x86_64 only.
Used during bootstrap to check that re-exported libraries are not dangling.
Fixes bootstrapping on macOS Big Sur.
8d04cd6
to
caf7f4b
Compare
I've rebased this onto |
Is there anything that can be done to help getting this merged? If there is anything to test, how do I best test it? |
building the major packages would be a good start, but as I don't have access to darwin hardware (and doing anything else is technically illegal), it's up to @NixOS/darwin-maintainers to merge this. |
@SuperSandro2000 if you could build some of the more major packages, I'm assuming this is good as unstable seems to be fine. However, we could be missing a PR which is correcting unstable behavior. |
@@ -41,6 +41,11 @@ stdenv.mkDerivation rec { | |||
"-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY" | |||
] ++ stdenv.lib.optionals (bareMetal) [ | |||
"-DCOMPILER_RT_OS_DIR=baremetal" | |||
] ++ stdenv.lib.optionals (stdenv.hostPlatform.isDarwin) [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
] ++ stdenv.lib.optionals (stdenv.hostPlatform.isDarwin) [ | |
] ++ lib.optionals (stdenv.hostPlatform.isDarwin) [ |
stdenv.lib is deprecated.
stdenv.lib.optional standalone "-DLLVM_ENABLE_LIBCXX=ON" ++ | ||
stdenv.lib.optional (!enableShared) "-DLIBCXXABI_ENABLE_SHARED=OFF"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stdenv.lib.optional standalone "-DLLVM_ENABLE_LIBCXX=ON" ++ | |
stdenv.lib.optional (!enableShared) "-DLIBCXXABI_ENABLE_SHARED=OFF"; | |
lib.optional standalone "-DLLVM_ENABLE_LIBCXX=ON" ++ | |
lib.optional (!enableShared) "-DLIBCXXABI_ENABLE_SHARED=OFF"; |
|
||
stdenv.mkDerivation { | ||
name = "print-reexports"; | ||
src = stdenv.lib.sourceFilesBySuffices ./. [".c"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src = stdenv.lib.sourceFilesBySuffices ./. [".c"]; | |
src = lib.sourceFilesBySuffices ./. [".c"]; |
I am against backporting any of these major stdenv changes to 20.09. If you are using Big Sur you either need to wait for 21.05 or use unstable until then. Any of those changes could break a lot and the Darwin maintainers are rare currently so I don't want to deal with any of the potential bugs. I can try to build a few packages but rebuilding stdenv never worked for me so I expect it to fail. Also I am not on Big Sur and I do not plan to update to it anytime soon. |
Note that a lot of macOS users do update their OS and this completely breaks their system currently on 20.09, so having fewer packages to work is better than zero. |
if any bigsur user wants to help this along, you can run a nixpkgs review of all the channel blockers and a package from most of the toolchains
|
The problem with this is that nixpkgs-review activates the sandbox which prevents rebuilds of stdenv on darwin. |
Oh.... that's awkward. And I was not aware of this. Guess I'm just having it easy in purity land. |
Is there a way to disable the sandbox? I have a Big Sur machine handy. Anything I can do to help? |
For nixpkgs-review. Not currently but I am talking to @Mic92 to solve this.
You can try building this PR and see if it even works. |
Tried building python3 without sandbox:
|
Yep, failed at the same spot as Sandro on Big Sur. |
Motivation for this change
This PR backports #98541 to 20.09. This is helpful for projects using NixOps that have a pinned nixpkgs commit to a stable NixOS release, in that circumstance, developers using Big Sur can't enter the
nix-shell
without these changes.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)