Repository navigation
Commit baafd7e
authored
Narrow the aten_device torch dependency to the ATen core (pytorch#22146)
`aten_device.h` uses `c10::Device` and the c10 diagnostic macros, so the
ATen and c10 core headers are all it needs. The target asked for the
whole `libtorch` external dep instead.
That matters because `:aten_bridge` exports `:aten_device`, and
`:aten_bridge` is a portable-mode target with public visibility. Any
application linking it therefore picked up the full `libtorch`. In build
environments where the `libtorch` external dep resolves to a library
that also registers every ATen operator, that collides with the
application's own operator registration library and the link fails with
duplicate symbols such as `at::compositeimplicitautograd::_cast_Byte`.
On Android the same thing shows up one level earlier, as two rules
producing the same shared library name.
`:aten_bridge` already declares `torch-core-cpp` for exactly this
reason, and every other `exported_external_deps = ["libtorch"]` in this
repo is guarded by `if aten_mode`. This change makes `:aten_device`
match.
The dep stays exported because `:aten_device` is header only and its
consumers, including `aten_bridge.h`, include the header directly.
## Test plan
In the open-source build both `libtorch` and `torch-core-cpp` map to the
same target, so this is a no-op here and CI should stay green.
The difference was checked in a build environment where the two names
resolve to different targets: a dependency query returns a path from the
`libtorch` target to the full operator registration library, and returns
nothing from the `torch-core-cpp` target to the same library.1 parent b584d82 commit baafd7e
1 file changed
Lines changed: 5 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
17 | 17 | | |
18 | 18 | | |
19 | 19 | | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
20 | 24 | | |
21 | | - | |
| 25 | + | |
22 | 26 | | |
23 | 27 | | |
24 | 28 | | |
| |||
0 commit comments