Use rapids_cmake_support_conda_env so executables link in any conda env#1275
Draft
rgsl888prabhu wants to merge 2 commits into
Draft
Use rapids_cmake_support_conda_env so executables link in any conda env#1275rgsl888prabhu wants to merge 2 commits into
rgsl888prabhu wants to merge 2 commits into
Conversation
libcuopt.so links gRPC, Protobuf, and Abseil as PRIVATE deps, so their SONAMEs end up in libcuopt.so's DT_NEEDED but are not propagated to consumer targets (cuopt_cli, cuopt_grpc_server, all tests). When ld links those consumers it walks libcuopt.so's DT_NEEDED to validate transitive symbol references and needs to locate libgrpc++.so.*, libprotobuf.so.*, libabsl_*.so.* on disk. Today this works only when the surrounding shell's LDFLAGS already carries -Wl,-rpath-link,$CONDA_PREFIX/lib (and/or -Wl,--allow-shlib-undefined), which is exported by the conda-forge compiler activation scripts shipped with cxx-compiler / gxx_linux-64 / gcc_linux-64. Conda envs missing those packages fail to link cuopt_cli and ~30 test executables, even though libcuopt.so itself builds successfully in the same run. Adopt the standard RAPIDS pattern (cudf, cuml, raft, rmm) by wiring $CONDA_PREFIX/lib into the build via rapids_cmake_support_conda_env, applied through link_libraries() with a BUILD_INTERFACE generator expression so the dependency is not recorded in the exported cuopt-config.cmake. - No-op when $CONDA_PREFIX is unset (e.g. manylinux wheel CI). - BUILD_INTERFACE keeps conda_env out of the installed cuopt CMake config; downstream find_package(cuopt) consumers are unaffected. - -L is link-time only; DT_NEEDED, INSTALL_RPATH and the wheel binaries are bit-identical to today. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
Initial attempt used link_libraries($<BUILD_INTERFACE:conda_env>), but CMake's export-validity check inspects INTERFACE_LINK_LIBRARIES before generator expressions are evaluated and still requires conda_env to be in an export set. The same check also failed on FetchContent-pulled papilo-core, which inherited conda_env via the directory-level command. Switch to the cudf pattern: drop the directory-level link, install conda_env into the cuopt-exports set, and add $<TARGET_NAME_IF_EXISTS: conda_env> per-target on cuopt, cuopt_cli, cuopt_grpc_server, and the ConfigureTest helper. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Ramakrishna Prabhu <ramakrishnap@nvidia.com>
Collaborator
Author
|
/ok to test ea972dc |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
libcuopt.solinks gRPC/Protobuf/Abseil as PRIVATE, so their SONAMEs end up inlibcuopt.so'sDT_NEEDEDbut aren't propagated to consumers (cuopt_cli,cuopt_grpc_server, all tests). Whenldlinks those targets it walkslibcuopt.so'sDT_NEEDEDto resolve transitive symbols and needs$CONDA_PREFIX/libon its search path. Today this only works when the conda env was created with the conda-forge compiler shims (cxx-compiler/gxx_linux-64/gcc_linux-64), whose activation scripts exportLDFLAGS=... -Wl,-rpath-link,$CONDA_PREFIX/lib -Wl,--allow-shlib-undefined .... Envs without those packages fail at link time oncuopt_cliand ~30 test executables, even thoughlibcuopt.soitself builds in the samebuild.shrun.Adopts the standard RAPIDS pattern (
rapids_cmake_support_conda_env, already used by cudf/cuml/raft/rmm).$<BUILD_INTERFACE:>keepsconda_envout of the installed cuopt CMake config; no-op when$CONDA_PREFIXis unset (wheel CI).Checklist