-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
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
darwin (Big Sur): tbd based stdenv #98541
Conversation
@@ -41,6 +41,8 @@ in | |||
|
|||
DarwinTools = callPackage ../os-specific/darwin/DarwinTools { }; | |||
|
|||
darwin-stubs = callPackage ../os-specific/darwin/darwin-stubs { }; |
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.
not sure we should expose this as a package
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.
This way makes it easy to provide to various libraries and does make debugging slightly easier in that you can nix-build -A darwin.darwin-stubs
. Did you have another mechanism in mind? I can imagine like treating them a bit like bootstrap tools and only propagating them in the stdenv definition.
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.
I'm in favour of keeping this exposed. And if only it will make debugging easier.
|
||
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.
Fine for now, but perhaps it would be best to move this to eg. the stubs repo in the future.
I rebased this against an eval and updated using the official bootstrap tools from hydra here LnL7@d7befca. |
Note that installer changes have been merged in Nix, so we only need to get this merged (and hopefully backport to 20.09) cc @NixOS/nixos-release-managers |
I included a reversion of the cctools bump here since it seemed to be causing problems (#101330). That's being addressed in other tickets (like #103053). Before merging we should drop that commit. I'm avoiding rebasing/removing for now because this branch is indirectly related to a hydra job set and I don't want to make it harder to debug. |
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.
7073fb3
to
3d00391
Compare
Closed by complete accident, sorry for the noise. |
|
||
src = fetchFromGitHub { | ||
owner = "thefloweringash"; | ||
repo = "darwin-stubs"; |
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.
if this is directly to support nixpkgs it would probably be a good idea to transfer the repo here? And also have darwin maintainers access to it
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.
I would definitely like to do this. I included it in the "Prerequisites" section, which isn't quite panning out as I expected.
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.
I think @domenkozar is one of the people with enough permissions to do that.
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.
If someone PM's him on IRC it should be pretty easy to have done
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.
@thefloweringash if you add me to that repo I can transfer it.
Big Sur will be be released tomorrow. What is left to do here? |
Used during bootstrap to check that re-exported libraries are not dangling.
This is an explicit impure reference in qtwebengine itself. This should probably be a library in the |
Does this commit change the viability of building nixpkgs on macOS with sandboxing enabled? I've tried that in the past, but always end up disabling it, because eventually some important package breaks. |
I doubt so, I believe for proper sandboxing we'll need to address how |
@angerman Ahh, right, it's some sort of limitation in Apple's own sandboxing mechanism. Now I remember :) |
There was a question on IRC if there is any plan on backporting this change to 20.09. |
I'd like to see this as well. If not even 20.03 but that might be a too tall ask. |
Awesome work @thefloweringash! This improves things greatly! |
That was me, I've opened #105799 to backport this. |
Needed on MacOS Big Sur due to NixOS/nixpkgs#98541.
Motivation for this change
This is an implementation of Text API (tapi, or
.tbd
files) based stdenv and Frameworks for Darwin. Closes #91748 and #19906.As of Big Sur the macOS filesystem no longer contains
.dylib
files and instead has a precomputed dyld cache. As a result the nixpkgs stdenv cannot link on Big Sur which vastly reduces the usability.Apple's SDK uses Text API descriptions of the contents of shared libraries. These
.tbd
files are straightforward YAML, can be passed directly to the linker and behave exactly like having.dylib
or framework files. The current implementation of the Darwin stdenv uses a combination of proxy dyld libraries and direct symlinks to system libraries. Switching from the proxy libraries and symlinks to linking against these.tbd
files is an improvement to compatibility and reproducibility.There are two main options for sources of
.tbd
files: Apple's SDK, or generating them from an existing installation of macOS viatapi stubify
. I assert that generating them is less likely to cause legal complications than deriving them from Apple's SDK. The darwin-stubs repository contains appropriate stubs generated from macOS 10.12.6. Technically either source should be trivially interchangeable so we're not locked into either here.If this branch is merged, then nixpkgs will be usable on Big Sur but not bootstrappable. The bootstrap environment requires the construction of a libSystem proxy in order to run the bootstrap tools. This shouldn't be much of a problem since a usable stdenv will be available from the binary cache. The easy solution is to regenerate the bootstrap tools once again after these changes have propagated.
I've spent some time testing on Big Sur and have been able to build my regular nix-darwin system closure which includes components written in rust, go, haskell (ghc), ruby, python, and using qt5. Note that the qt5 patch included here is the simplest thing that can work and is not generally applicable to upstream. I'm assuming upstream will produce a correct fix soon.
Prerequisites:
including review and merge of "stdenv/darwin: assemble full clang toolchain" stdenv/darwin: assemble full clang toolchain #94427This PR will need to be updated after these prerequisites are satisfied. Opening now as a draft to have a description of the overall plan and to tie the prerequisites together.
cc @matthewbauer and @LnL7
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)