fix(cdi): include 32-bit libraries in discovery

[elibosley]

Summary

CDI generation omitted the host's 32-bit NVIDIA driver stack on multilib systems; this combines predefined-path and linker-cache discovery so generated specs include both native and compat32 libraries.

Why This Exists

ldcache.List() returns separate 32-bit and 64-bit library sets, but the CDI lookup path discarded the 32-bit set. The default library locator also stopped after finding libraries in a predefined native path, which prevented the linker cache from contributing libraries installed in a separate compat32 directory.

The resulting CDI spec could expose the 64-bit NVIDIA stack while leaving a 32-bit Vulkan application such as a Steam or Proton title without the matching vendor libraries. In that state, the application can select software rendering even though compatible ELF32 NVIDIA libraries are installed on the host.

This is related to #563, which tracks broader graphics-library coverage.

Resolution

The default library locator now merges predefined-path and linker-cache results and deduplicates the combined list. Linker-cache discovery consumes both architecture lists, with native libraries first so existing version-inference precedence remains stable.

This keeps architecture discovery in the host linker cache rather than adding distribution-specific compat32 paths to CDI generation.

Reviewer Considerations

• Please confirm that an exported lookup.Merge combinator is the preferred shape for combining locator results; it mirrors the existing exported lookup.First behavior while retaining successful matches when another locator fails.
• The default locator now returns all unique matches instead of the first successful source. This is intentional because CDI needs every driver-library directory, but callers that infer a driver version still see native libraries first.
• Multilib hosts will generate larger CDI specs because valid ELF32 driver libraries are now included. Hosts without 32-bit linker-cache entries should be unchanged.
• This PR is limited to discovery and regression coverage. It does not add distribution-specific paths or modify runtime selection policy.

Behavior Changes

• CDI specs generated on multilib hosts include matching 32-bit NVIDIA driver libraries exposed through the host linker cache.
• Native library ordering is preserved for callers that use the first match.
• Duplicate paths found through predefined directories and the linker cache are emitted once.

Implementation Summary

• Consume both values returned by ldcache.List().
• Add a locator combinator that merges successful results across lookup sources.
• Use the merged, unique locator for default library discovery.
• Add regression tests for mixed 32-bit/64-bit linker-cache entries, ordering, result merging, and partial lookup failure.

Verification

• make test passed.
• go run github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest run --timeout 5m ./... passed with 0 issues.
• go vet ./pkg/lookup passed.
• git diff --check passed.
• Real-host comparison on an x86_64 linux-based system with NVIDIA 595.84:
  • toolkit 1.19.1 generated 40 /usr/lib64 library mounts and 0 /usr/lib library mounts;
  • patched main generated 41 /usr/lib64 library mounts and 25 /usr/lib library mounts;
  • the newly discovered /usr/lib entries were verified as ELF32 and included libcuda, libnvidia-ml, and libGLX_nvidia.
• The host's live CDI specification was not replaced during validation.
• The commit has a matching DCO sign-off and a GitHub-verified SSH signature.

Risk

Low to moderate. The discovery set intentionally grows on multilib hosts, and the primary compatibility risk is a caller assuming only one architecture is returned. Native-first ordering, deduplication, package tests, the full upstream test suite, and real-host CDI generation cover that behavior.

[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.

[myeolenv]

Thanks for the contribution. We will review this PR.

[henry118]

Hi @elibosley, thanks for the contribution, the idea makes sense.

One thing I'd suggest is to gate this behind an opt-in flag rather than making it default behavior.

libnvidia-container's legacy path already treats this as opt-in (--compat32) feature, worth preserving that behavior rather than switching to always-on.

We need to gate it because on musl-based containers (e.g. Alpine+gcompat), both the 32-bit and 64-bit library directories get appended into a single /etc/ld-musl-<arch>.path with no arch tagging. if musl's dynamic linker finds a library (by name) with the wrong arch, the workload would fail.

[henry118]

@elibosley just checking in — are you still planning to continue working on this PR? If not, we can close it for now and reopen it when you're ready to pick it back up.

[ehfd]

Opened #2035.

[elibosley]

@henry118 apologies, I am terrible at checking my GitHub notifications there are just too many 🥲 - sounds like you guys have it from here! Thank you for checking this out I appreciate it!

[henry118]

Thanks @elibosley . I'll close this PR and track of work in #2035 instead.