For more information, see the build log attached at the end of this message. Return on first glance, it looks like Bazel identifies and saves the platform CPU name as aarch64, and later fails to match any macOS toolchains to it, because all of them have been renamed as a result of the above pull request. In my local Bazel cache, the host platform is identified as aarch64, as evidenced by the following autogenerated platform config file:.In Correct cpu and os values of local_config_cc_toolchains targets #14995, the aarch64 macOS CPU constraint value was renamed to arm64.
He suspects that it is a Bazel issue, based on the following observations: I already talked to a JAX core developer who typically answers build-related questions on the project. The reason that Bazel 5.1.0 became necessary to use now is that there were some changes in Tensorflow's BUILD definitions, and thus, as JAX depends on Tensorflow for XLA, also of JAX's build process. Setting the toolchain debug flag reveals that the problem is a toolchain resolution failure (see the error below). When pulling in JAX main today at HEAD and trying to build from source, the build script downloaded Bazel version 5.1.0 for macOS ARM64 from GitHub ( this is important), started the build, and failed. My last successful build was about two weeks ago. I have been using Bazel 5.0.0 to (successfully) build jaxlib from source on my machine (Apple M1 Pro, macOS 12.3.1) in the past. Description of the problem / feature request:Ĭrosspost from this JAX issue on building jaxlib from source.
0 kommentar(er)
