-
-
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
python3Packages.jaxlib: fix darwin build #184395
Conversation
@ofborg build python39Packages.jaxlib |
@ofborg build python3Packages.jaxlib |
1bc9886
to
7e1677c
Compare
I don't have x86_64-darwin to test, but I can try on aarch64-darwin |
On ofborg it failed to build |
Ah no I remembered it wrong, it was because it can't find a |
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.
Thanks for contributing this! Getting jaxlib support on Darwin would be a big win!
To some extent I'm flying blind here without access to x86_64-darwin hardware, but I have a few questions first anyhow...
# Make sure Bazel knows about our configuration flags during fetching so that the | ||
# relevant dependencies can be downloaded. | ||
bazelFetchFlags = bazel-build.bazelBuildFlags; | ||
|
||
bazelBuildFlags = [ |
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.
Why was this removed and merged into a single bazelFlags
? It looks like we're losing bazelFetchFlags
entirely?
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.
bazelFlags
are inherited by both the build (
inherit name bazelFlags bazelBuildFlags bazelFetchFlags bazelTarget; |
inherit bazelFlags bazelBuildFlags bazelFetchFlags bazelTarget; |
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.
Gotcha, thanks for explaining. In that case, could we keep that comment -- or something analogous -- explaining why we need those flags passed to both steps?
if stdenv.targetPlatform.isLinux then | ||
"manylinux2010_${stdenv.targetPlatform.linuxArch}" | ||
else if stdenv.targetPlatform.isDarwin then | ||
"macosx_10_9_${stdenv.targetPlatform.linuxArch}" |
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.
Why macosx_10_9
? It looks like the pypi wheels are using the macosx_11_0
tag already: https://pypi.org/project/jaxlib/#files.
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.
note to self: we should also update to manylinux_2014
as it seems that's what upstream is doing nowadays as well
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.
That comes from https://github.com/google/jax/blob/jaxlib-v0.3.0/build/build_wheel.py#L261-L262, looks like macosx_11_0
is only used for arm on 0.3.0
.
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.
ah I see... very good catch. And I guess for the time being we will only support x86_64-darwin anyhow?
pkgs/top-level/python-packages.nix
Outdated
buildBazelPackage = pkgs.buildBazelPackage.override { | ||
stdenv = pkgs.darwin.apple_sdk_11_0.stdenv; | ||
}; |
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 seems like the kind of thing we should only do on Darwin?
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.
Yeah you're right, https://nixos.org/manual/nixpkgs/unstable/#sec-darwin documents that this is fine:
On Linux, this will have the same effect as pkgs.callPackage, so you can use pkgs.darwin.apple_sdk_11_0.callPackage regardless of platform.
but it's unintuitive enough that I'll make this conditional.
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.
ah I see. yeah I think sticking to a conditional given the unintuitive-ness is a good idea
7e1677c
to
994233f
Compare
Addressed review. |
994233f
to
c0e6ce4
Compare
Fixed it on |
c0e6ce4
to
fabdb34
Compare
Sadly it seems that darwin builds may be re-broken until we can get macOS SDK 10.14 into nixpkgs (#183051) 😞 |
That should be ok at least from an SDK point of view, we're using the macOS 11.0 SDK here, that's what the |
fabdb34
to
98b5b80
Compare
Does anyone know why ofborg won't pick up |
@ofborg build python3Packages.jaxlib python39Packages.jaxlib |
Would also be good to figure out why the linux derivations fail to evaluate on ofborg, they build properly in hydra. |
@ofborg build python3Packages.jaxlib |
Result of 34 packages marked as broken and skipped:
10 packages failed to build:
|
Hmm I'm having trouble building on aarch64-darwin: https://gist.github.com/samuela/471a67182e4c7dded61675fba72f18cf. Looks like it may be a 404 |
That's a red herring, it's strange that it's not available on the bazel mirror, but it will get it from github: bazelbuild/rules_cc@081771d. The error is:
Are you sure you checked out the latest commit? That's what the patch file is supposed to fix. |
I'm seeing the same error on ofborg, will try to repro, there might be something wrong with my own setup. |
But maybe let's merge the working |
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.
Hey @uri-canva, apologies for the delay! I have a lingering comment about using fetchpatch
and one place where I think a comment might be useful. But after this I think we should be good to merge!
@@ -232,17 +239,31 @@ let | |||
# 4) Patch tensorflow sources to work with later versions of protobuf. See | |||
# https://github.com/google/jax/issues/9534. Note that this should be | |||
# removed on the next release after 0.3.0. | |||
# 5) Patch in https://github.com/bazelbuild/rules_cc/pull/136 to fix the bazel compiler detection on aarch64-darwin |
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.
Thanks for filling this upstream! Since that's done, let's just pull it via fetchpatch
here instead of copying the patch file into nixpkgs's tree.
Alternatively we can remove it for now since AFAIU the aarch64-darwin build is not yet functional anyhow?
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 don't think fetchpatch
will work: the commit is on a PR, so when the PR is merged / closed and the branch deleted it will eventually be garbage collected. I'll remove it then.
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 is a common pattern in other packages in nixpkgs. It's generally preferred to fetchpatch commits rather than PRs/branches, since PRs are mutable. That's an interesting question re commits being deleted... I'm not sure how that's handled. Perhaps they just link to privately controlled forks of repos? Idk...
98b5b80
to
cd8be9b
Compare
cd8be9b
to
c556715
Compare
c556715
to
633d5cb
Compare
platforms = platforms.unix; | ||
# aarch64-darwin is broken because of https://github.com/bazelbuild/rules_cc/pull/136 | ||
# however even with that fix applied, it doesn't work for everyone: | ||
# https://github.com/NixOS/nixpkgs/pull/184395#issuecomment-1207287129 | ||
broken = stdenv.isAarch64; |
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.
Updated the meta to reflect the new state of platform support. Given that I got it working on aarch64-darwin
(albeit only on my machine) I assume that not building on aarch64-linux
is because something is broken, not because it's not supported.
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.
Maybe it even builds correctly, I haven't tried.
@ofborg build python3Packages.jaxlib |
The failure on ofborg is:
I've had that locally when nix was confused on what the current system architecture was, because it was running on an M1 with rosetta, but I'm not sure why that would happen on an x86_64 mac. I've seen in it some of the past builds too, but not all, so it seems to only affect specific machines. |
Huh, very odd... doesn't look like your fault in any case. I would be curious to figure out the underlying issue, but doesn't need to be in scope for this particular PR. |
Thanks for all your hard work on this @uri-canva! These changes LGTM and are a big leap forward in terms of our ability to support more platforms. |
substituteInPlace ../output/external/rules_cc/cc/private/toolchain/osx_cc_wrapper.sh.tpl \ | ||
--replace "/usr/bin/install_name_tool" "${cctools}/bin/install_name_tool" | ||
substituteInPlace ../output/external/rules_cc/cc/private/toolchain/unix_cc_configure.bzl \ | ||
--replace "/usr/bin/libtool" "${cctools}/bin/libtool" |
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 broke jaxlib
on non-Darwin because cctools
is Darwin-specific.
broken = !stdenv.targetPlatform.isDarwin; # Only supports darwin targets |
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.
Unfortunate, it wasn't evaluating on ofborg so I couldn't check, have you already fixed it? I'll put up a fix.
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.
Description of changes
Fix the darwin build for jaxlib.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes