[BUG] Build-tree libcuopt.so resolves librmm from the conda prefix instead of its own _deps, failing at dlopen

[ramakrishnap-nv]

Describe the bug

cpp/build/libcuopt.so records the conda prefix before its own CPM _deps directories in DT_RPATH:

RPATH  /path/to/conda/envs/cuopt/lib:$ORIGIN:/path/to/cpp/build/_deps/rmm-build:/path/to/cpp/build/_deps/rapids_logger-build:

When CPM fetches its own rmm — which it does whenever the conda prefix has a different version — libcuopt is compiled against the fetched headers but resolves librmm.so from conda at load time. rmm encodes its version in an inline namespace, so the link succeeds and dlopen then fails:

undefined symbol: _ZTIN3rmm10_RMM_26_109bad_allocE

DT_RPATH is searched before LD_LIBRARY_PATH, so no path variable fixes it. The only workarounds are LD_PRELOAD or relinking.

Steps/Code to reproduce bug

In a conda environment whose rmm differs from the version cpp/CMakeLists.txt pins:

./build.sh libcuopt
./cpp/build/tests/linear_programming/C_API_TEST
# -> symbol lookup error: .../libcuopt.so: undefined symbol: _ZTIN3rmm10_RMM_26_109bad_allocE

# works only with an explicit preload:
LD_PRELOAD=$PWD/cpp/build/_deps/rmm-build/librmm.so ./cpp/build/tests/linear_programming/C_API_TEST

Expected behavior

A build-tree consumer should resolve the rmm that libcuopt was compiled against. The _deps directories should precede the conda prefix in RPATH, or the build should use RUNPATH so LD_LIBRARY_PATH can win.

Environment overview

Local source build from main, conda environment, Linux x86_64.

Additional context

This is not Java-specific — it affects anything loading the build-tree libcuopt.so, including cuOpt's own C_API_TEST. It surfaced while adding the ./build.sh java target in #1524, where it had to be worked around with a CUOPT_PRELOAD_LIBS escape hatch in java/cuopt/scripts/test.sh. That workaround can be removed once the ordering is fixed.

The same reasoning applies to librapids_logger.so.