Four independent build and packaging issues in the CUDA backend and wheel

[shoumikhin]

These came up while working on the wheel's C++ components. None are caused by that
work, and each reproduces independently, so they are worth separate attention
rather than being folded into an unrelated change.

A CUDA build with default settings does not compile

backends/cuda/runtime/shims/int4_plain_mm.cuh:250 uses __dp4a, which requires
compute capability 6.1 or newer. Nothing in the build sets a default
CMAKE_CUDA_ARCHITECTURES, so a plain CUDA build picks whatever the toolkit
defaults to and fails with:

error: identifier "__dp4a" is undefined

Passing an explicit architecture works around it, for example 90 on a datacenter
GPU or 110 on Jetson Thor. A sensible default in the build, or a guard around the
intrinsic with a portable fallback, would let a CUDA build work out of the box.

The CUDA backend requires a newer CMake than the project declares

The repository root declares:

cmake_minimum_required(VERSION 3.24)

while backends/cuda/CMakeLists.txt:17 declares:

cmake_minimum_required(VERSION 3.29)

Any environment with a CMake between those two versions can configure the project
but not a CUDA build. On a stock Ubuntu 24.04 image, which ships CMake 3.28, this
fails with CMake 3.29 or higher is required. Either the root floor should rise or
the CUDA backend should work at the declared minimum.

The data loader extension carries a second copy of the operator table

extension/pybindings/data_loader links the static core, so the shipped module
defines the operator registration symbols itself:

nm -DC data_loader...so | grep register_kernels   -> 1 definition

The module only exposes a pybind type and calls into no runtime symbols at all
(nm reports zero undefined ExecuTorch symbols), so the static core brings in a
duplicate registry for no benefit. It also adds a couple hundred kilobytes to the
wheel. This predates the shared-runtime work; the module linked the same way
before.

The manylinux baseline is inconsistent for aarch64

The builder image and the auditwheel repair target do not agree on one manylinux
baseline: the image is built against manylinux_2_39 while repair requests
2_28. Publishing aarch64 wheels should settle on a single baseline first,
otherwise the tag a wheel claims and the glibc it was actually built against can
diverge.

[shoumikhin]

One more, found while looking at aarch64 wheel builds.

aarch64 py3.14 wheel builds cannot install their dependencies

build-wheel-py3_14-cpu-aarch64 fails during the pre-build step, before anything
in this repository is compiled. The chain is:

.ci/scripts/wheel/pre_build_script.sh
  -> install_requirements.py
    -> pip install -r requirements-examples.txt
      -> datasets == 3.6.0 pulls in pyarrow
        -> no prebuilt pyarrow wheel for aarch64 py3.14, so pip builds it
          -> pyarrow's build invokes cmake and it fails:

File ".../bin/cmake", line 3, in <module>
  from cmake import cmake
ModuleNotFoundError: No module named 'cmake'

So the cmake entry point in the build environment is a Python shim whose module
is not importable. pyarrow's build_ext shells out to it and gets a traceback
instead of a configure.

This only affects py3.14 because 3.10 through 3.13 resolve a prebuilt pyarrow wheel
and never run a source build. It affects both architectures in principle, but in
practice shows on aarch64 py3.14.

Options, roughly in order of how contained they are: pin pyarrow to a version
with an aarch64 py3.14 wheel, install cmake into the build environment so the
shim resolves, or drop the example requirements from the wheel pre-build since a
wheel build does not need them.

[shoumikhin]

One more, found while checking the runtime paths of shipped libraries.

Shipped libraries carry absolute build-directory paths

Packaging copies binaries out of the CMake build directory, and CMake only rewrites
a target's runtime path during cmake --install, which packaging never runs.
Nothing sets BUILD_WITH_INSTALL_RPATH either, so every shipped library keeps the
runtime path it was linked with, including absolute paths that exist only on the
build machine:

Library rpath: [$ORIGIN/../../../torch/lib:...:/<builder>/pip-out/temp.<plat>/cmake-out:...]

This is not new. Measured on a published wheel and on a current build:

published wheel:   5 of 10 shipped libraries carry build-directory paths
current build:    11 of 15 shipped libraries carry build-directory paths

The ratio is similar, so the behavior predates the recent packaging work; more
libraries simply means more instances of it.

It does not break loading, because the relative $ORIGIN entries come first and
resolve correctly. Verified by relocating a library plus its dependency into a
fresh tree with no build directory present: resolution went through the relative
entry.

Two reasons it is still worth fixing:

• The paths leak the layout of whoever built the wheel into a published artifact.
• They make local verification unreliable. On a build machine, a library whose
  relative path is wrong can still resolve through a leftover absolute entry, so
  ldd reports success for the wrong reason. A missing runtime path is then
  invisible until someone runs on a clean machine.

Either packaging should copy from an install tree so CMake rewrites the paths, or
the build should set BUILD_WITH_INSTALL_RPATH for shipped targets. Both touch
every component, which is why this is reported rather than folded into an
unrelated change.