fix(nvjitlink-sys): find libnvJitLink under lib/ as well as lib64/

[lucifer1004]

What this adds

nvjitlink-sys now probes <root>/lib/libnvJitLink.so after <root>/lib64/libnvJitLink.so under each CUDA root, so a toolkit laid out with lib/ (conda-forge, and nixpkgs as the in-tree flake joins it) gives the finalizer an exact file to fingerprint and cargo oxide build --materialize-cubin works on such machines. Installer layouts keep lib64/ first and behave as before. The materialization refusal now says which variables to set.

# conda-forge machine: nvJitLink at $CONDA_PREFIX/lib/libnvJitLink.so, no lib64/
export CUDA_HOME=$CONDA_PREFIX
cargo oxide run vecadd --arch sm_120 --materialize-cubin

before: probes $CUDA_HOME/lib64/..., /usr/local/cuda/lib64/..., /opt/cuda/lib64/... (3 misses),
        then dlopen("libnvJitLink.so.13") by name
        -> CUDA materializer discovery failed: the loaded libNVVM or nvJitLink library
           cannot be tied to an exact file; refusing materialization ...          (exit 2)
after:  probes $CUDA_HOME/lib64/..., then $CUDA_HOME/lib/libnvJitLink.so
        -> Output format: materialized cubin ... SUCCESS: All 1024 elements correct!  (exit 0)

// nvjitlink-sys: the candidates probed under each root, lib64 first
fn library_candidates(roots: &[PathBuf]) -> Vec<PathBuf> {
    roots
        .iter()
        .flat_map(|root| ["lib64", "lib"].map(|dir| root.join(dir).join("libnvJitLink.so")))
        .collect()
}

What we fixed

• open_library joined only lib64/libnvJitLink.so under each root. A root laid out with lib/ fell through to the SONAME branch, which carries no file identity, so the materializer handshake is None and both the cargo oxide helper and the backend refuse materialization.
• With a system toolkit present and CUDA_HOME at a lib/ root, main silently took the system nvJitLink while libNVVM came from the configured root. Both now come from the configured root.
• The refusal names LIBNVVM_PATH, LIBNVJITLINK_PATH, CUDA_TOOLKIT_PATH and CUDA_HOME, and calls the SONAME load the usual cause.

Implementation

• library_candidates(roots) yields <root>/lib64/libnvJitLink.so then <root>/lib/libnvJitLink.so per root. open_library iterates it through the unchanged open_library_path (canonicalize, retained /proc/self/fd load, identity capture), so a lib/ hit is fingerprinted the same way a lib64 hit is, and a missing or unloadable file falls through to the next candidate.
• LIBNVJITLINK_PATH first and the SONAME fallback last are unchanged. libnvvm-sys is untouched because these layouts keep nvvm/lib64/.
• Tests: the candidate-order unit test, plus a Linux regression through a small open_library_under_roots seam that loads a probe DSO from <root>/lib/ with no lib64/ and checks the retained identity, lib64-first precedence and the empty-root negative case.
• Docs: the nvjitlink-sys README, the cuda-host ltoir discovery docs and the cargo oxide doctor hint describe the new order and the unversioned-name limit.

Verification

Checked at a00a3da13 (nightly-2026-10-11, RTX 5090):

• ✅ cargo test -p nvjitlink-sys (16 passed, 3 ignored toolkit tests, doctest passed), -p cargo-oxide (255), -p cuda-artifact-finalizer (33), -p cuda-host (108); clippy and rustdoc with warnings as errors; fmt; the lock check; all 18 guards.
• ✅ Fails before, passes after: with main's lib64-only loop, two of the three new tests fail; with this branch all pass.
• ✅ Mount namespace with /usr/local/cuda-13.4 and -13.3 hidden and CUDA_HOME at a conda-style root (lib/libnvJitLink.so.13.4.92, nvvm/lib64/libnvvm.so, no lib64/): main exits 2 with the refusal; this branch prints Output format: materialized cubin and SUCCESS: All 1024 elements correct!, with the root's lib/ copy as the fingerprinted file. memcheck on the materialized vecadd: 0 errors.
• ✅ Controls: CUDA_HOME unset gives byte-identical handshakes before and after; a root with both directories still picks lib64/; a broken lib/ candidate falls through to the next root; plain vecadd.ptx identical to main.
• ✅ Author: conda-forge CUDA 13.2 with CUDA_HOME=$CONDA_PREFIX, main fails with the refusal and this branch materializes and runs on an RTX PRO 6000.

Caveats

• Only the unversioned libnvJitLink.so is probed under a root. A runtime-only conda env or a pip wheel that ships only libnvJitLink.so.13 still takes the SONAME route and is refused for materialization; LIBNVJITLINK_PATH at the versioned file works and is what the message now says.
• A configured root whose lib/libnvJitLink.so is older than the toolkit's libNVVM now fails loudly in nvJitLink where main used the system copy by accident.
• Linux only; Windows discovery is untouched.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[nihalpasham]

/ok to test a00a3da

[nihalpasham]

Thanks, this is the right fix: the probe loop is the one place every consumer reaches nvJitLink through, and lib64 stays first. On top:

• Merged main so the two files live under cuda-oxide/, and brought the discovery docs in line with the new order (the nvjitlink-sys README, the cuda-host ltoir docs, the cargo oxide doctor hint). They also record the limit: only the unversioned libnvJitLink.so is probed under a root, so a layout that ships only libnvJitLink.so.13 still needs LIBNVJITLINK_PATH.
• Reworded the refusal to name every discovery variable and to call the SONAME load the usual cause rather than the only one.
• Added a Linux regression that loads a probe DSO from <root>/lib/ with no lib64/: retained identity, lib64-first precedence and the empty-root negative case.

I reproduced both sides here: with the system toolkit hidden and CUDA_HOME at a conda-style root, main refuses materialization and this branch materializes and runs vecadd on the 5090 with the root's lib/libnvJitLink.so as the fingerprinted file. At a00a3da13 the four crates' tests, clippy, rustdoc, fmt, the 18 guards and all CI checks passed. #1317 is about the ffi examples' headers and stays open.