Skip to content
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

Merged
merged 18 commits into from Nov 12, 2020
Merged

Conversation

thefloweringash
Copy link
Member

@thefloweringash thefloweringash commented Sep 23, 2020

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 via tapi 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:

This 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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@@ -41,6 +41,8 @@ in

DarwinTools = callPackage ../os-specific/darwin/DarwinTools { };

darwin-stubs = callPackage ../os-specific/darwin/darwin-stubs { };
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Contributor

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"];
Copy link
Member

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.

pkgs/stdenv/darwin/default.nix Outdated Show resolved Hide resolved
pkgs/stdenv/darwin/default.nix Show resolved Hide resolved
@domenkozar domenkozar changed the title darwin: tbd based stdenv darwin (Big Sur): tbd based stdenv Oct 15, 2020
@LnL7
Copy link
Member

LnL7 commented Oct 18, 2020

I rebased this against an eval and updated using the official bootstrap tools from hydra here LnL7@d7befca.
This comparison should give a decent view of the general state of things with these changes.

@domenkozar
Copy link
Member

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

@LnL7 LnL7 added this to Big Sur in Darwin Oct 24, 2020
@thefloweringash
Copy link
Member Author

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.

LnL7 and others added 4 commits November 9, 2020 19:59
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.
@thefloweringash
Copy link
Member Author

Closed by complete accident, sorry for the noise.


src = fetchFromGitHub {
owner = "thefloweringash";
repo = "darwin-stubs";
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Contributor

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

Copy link
Member

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.

@thefloweringash thefloweringash marked this pull request as ready for review November 9, 2020 13:23
@domenkozar
Copy link
Member

Big Sur will be be released tomorrow. What is left to do here?

@thefloweringash
Copy link
Member Author

tested this with qt5.qtwebengine (qtwebengine-5.12.7) on macOS BigSur (x86_64). Fails with:

ninja: error: '../../../../../../../../../../../usr/lib/libsandbox.1.dylib', needed by 'obj/components/cdm/renderer/librenderer.a', missing and no known rule to make it

@thefloweringash: It looks like pkgs/development/libraries/qt-5/5.12/qtbase.patch.d/0015-qtbase-tbd-frameworks.patch doesn't catch this

This is an explicit impure reference in qtwebengine itself. This should probably be a library in the pkgs/os-specific/darwin directory. Since I missed it from the stubs, we'll need to add it there first, and then wrap it as a library. See NixOS/darwin-stubs#3.

@dhess
Copy link
Contributor

dhess commented Nov 19, 2020

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.

@angerman
Copy link
Contributor

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 nix does sandboxing on macOS, as it keeps running into limits when it sets them up.

@dhess
Copy link
Contributor

dhess commented Nov 19, 2020

@angerman Ahh, right, it's some sort of limitation in Apple's own sandboxing mechanism. Now I remember :)

@LnL7 LnL7 moved this from Big Sur to Done in Darwin Nov 22, 2020
@FRidh
Copy link
Member

FRidh commented Nov 29, 2020

There was a question on IRC if there is any plan on backporting this change to 20.09.

@angerman
Copy link
Contributor

@angerman Ahh, right, it's some sort of limitation in Apple's own sandboxing mechanism. Now I remember :)

I think it's more like: nix could be smarter about this. I believe @LnL7 had some ideas for this. But memory is fuzzy.

@angerman
Copy link
Contributor

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.

@matthewbauer
Copy link
Member

Awesome work @thefloweringash! This improves things greatly!

@davidtwco
Copy link
Member

There was a question on IRC if there is any plan on backporting this change to 20.09.

That was me, I've opened #105799 to backport this.

@toonn toonn mentioned this pull request Mar 14, 2021
@thefloweringash thefloweringash deleted the darwin-tapi-stdenv branch March 16, 2021 14:24
georgefst added a commit to georgefst/cross-haskell-app that referenced this pull request Jul 15, 2021
Needed on MacOS Big Sur due to NixOS/nixpkgs#98541.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Darwin
  
Done
Development

Successfully merging this pull request may close these issues.

None yet