Repository navigation
CUDA wheel: check every dependency, and give torch_cpu_library targets torch's compile settings back - #24087
Merged
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24087
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 9cb582b with merge base b578b2e ( BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 22, 2026 20:48
dad4443 to
c520aa1
Compare
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 23, 2026 10:15
c520aa1 to
76d4404
Compare
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 23, 2026 11:06
76d4404 to
9cb582b
Compare
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 23, 2026 17:45
9cb582b to
76c4b48
Compare
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 23, 2026 18:58
76c4b48 to
8209f88
Compare
JacobSzwejbka
approved these changes
Oct 23, 2026
The CUDA wheel smoke test checked that no shipped library records libtorch_cuda.so or libc10_cuda.so. That misses other libraries that only a CUDA build of torch installs. The wheel before the linking fix also recorded libnvrtc.so.13 on the LLM runner module. With the two names removed, the old check passed while that module still failed to import next to a CPU-only torch. Turn it into an allow list. Every recorded dependency must be shipped in the wheel, be one of the torch libraries a CPU-only torch also has, be part of the C and C++ system runtime, or be installed by a package that a plain install of the wheel requires (today that is the CUDA runtime). A requirement behind an extra, or for another platform, is skipped, so an optional package that happens to be installed does not widen the list. The check compares names only. It does not load anything.
The same three-line comment sat at five link sites. It explained why the line does not link torch, but not what torch_cpu_library does differently, and "in a CUDA build" read as our own CUDA option rather than how PyTorch was built. Each site now says that torch records libtorch_cuda with a CUDA build of PyTorch, so a CPU-only torch could not load the library, and that torch_cpu_library does not. At aten_bridge the old reason did not apply. aten_bridge is a static library and is never loaded on its own. Its link matters because it is passed on to _training_lib. But it was only static by default: with BUILD_SHARED_LIBS=ON it became a shared library. Mark it STATIC so the comment holds in every layout. Nothing installs it and only _training_lib links it.
Linking the torch target does more than link. TorchConfig also gives it TORCH_INCLUDE_DIRS, which CMake treats as system headers because the target is imported, TORCH_CXX_FLAGS, and on recent torch a minimum C++ standard (C++20). torch_cpu_library, which our targets now link instead so that a CPU-only torch can load them, only passes on torch/include. So those targets changed. torch/csrc/api/include became a normal include directory, so warnings inside torch's headers are now reported as if they were our code. And a TORCH_CXX_FLAGS set at configure time no longer reached them. For example, compiling kernels/portable/cpu/op_allclose.cpp with -Wall -Wextra -Werror went from no errors to 25 errors, all inside torch's headers. Default builds were not affected. find_package_torch now copies torch's interface include directories, compile options and compile features to torch_cpu_library. It does this once, also when the project found torch before calling it. Every target that links torch_cpu_library, directly or through a PUBLIC link such as custom_ops_aot_lib, now gets these settings, and a new link site cannot forget them. With a CUDA build of PyTorch, torch also carries the CUDA include directory and definitions of torch_cuda_library. Those are not copied, since these targets do not use CUDA. Changing torch_cpu_library itself also affects any other target in the build that links it. When there is no torch_cpu_library, for example with a static libtorch or a parent project that defines its own torch target, nothing is copied. A new test configures a small project and checks that a target linking torch_cpu_library, directly or through a PUBLIC link, gets torch's C++ API include directory, TORCH_CXX_FLAGS and, when torch sets one, its C++ standard. It checks both when find_package_torch finds torch and when the project found it first. A second test checks that find_package_torch still configures when only a torch target exists. Both pass with CPU and CUDA builds of torch. The first fails without this change, and the second fails if the copy does not first check that torch_cpu_library exists.
shoumikhin
force-pushed
the
cuda-wheel-dep-followups
branch
from
October 23, 2026 19:54
8209f88 to
12e8521
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
#24060 made the Linux CUDA wheel load next to a CPU-only PyTorch by linking
torch_cpu_libraryinstead oftorch. Three things were too weak.libtorch_cuda.soandlibc10_cuda.so.libnvrtc.so.13and other CUDA libraries slipped through.torchalso brings its include directories as system headers,TORCH_CXX_FLAGS, and on recent torch a C++ standard.torch_cpu_librarymisses most of them. So warnings inside torch's headers are reported as ours, and a configuredTORCH_CXX_FLAGSis dropped.torch_cpu_libraryis used. Ataten_bridgethe reason was wrong.Fix
torchrecordslibtorch_cudawith a CUDA build of PyTorch, andtorch_cpu_librarydoes not.aten_bridgeis nowSTATIC, as its comment assumes.find_package_torchcopies torch's interface include directories, compile options and compile features totorch_cpu_libraryonce, so every target in the build that linkstorch_cpu_librarygets them. The CUDA settings a CUDA build of PyTorch adds totorchare not copied. If there is notorch_cpu_library, as with a static libtorch, nothing is copied.Testing
torch_cpu_library, also through aPUBLIClink, get the C++ API include directory,TORCH_CXX_FLAGSand, when torch sets one (the 2.16 nightly does, 2.14 does not), the C++ standard, also when torch was found first. A second test checks thatfind_package_torchconfigures when only atorchtarget exists. Both pass on Linux x86-64 with torch 2.14.0 (CPU, CUDA 13.0) and a 2.16 CUDA 13.2 nightly, and on macOS arm64 with 2.14.0 CPU. Each fails without its part of the change.libnvrtc.so.13and three more.op_allclose.cppwith-Wall -Wextra -Werror: 25 errors in torch headers without the change, none with it.BUILD_SHARED_LIBS=ON,aten_bridgeis now static and_training_libbuilds.