NVIDIA / NVIDIA/cudf

[BUG] libcudf tests warn when linking when building in a conda environment without conda compiler metapackages

Open
#11,120 2 comments 0 reactions 0 assignees View on GitHub
0 - Backlog bug CMake
Dominant language
C++
Stars
9.8k
Forks
1.1k
Avg merge
3d 6m
Merged PRs (30d)
278

Description

When building libcudf and tests in a conda environment without having the compiler metapackages installed (`c-compiler`, `cxx-compiler`, etc.), it produces warnings about not finding `libz.so.1` needed by `libcudf.so`:
```
[406/674] Linking CXX executable gtests/COLUMN_TEST
/home/keith/miniconda3/envs/dev/bin/../lib/gcc/x86_64-conda-linux-gnu/10.3.0/../../../../x86_64-conda-linux-gnu/bin/ld: warning: libz.so.1, needed by libcudf.so, not found (try using -rpath or -rpath-link)
```

I believe this is due to both the `conda_env` target (https://github.com/rapidsai/cudf/blob/branch-22.08/cpp/CMakeLists.txt#L628) and the zlib target (https://github.com/rapidsai/cudf/blob/branch-22.08/cpp/CMakeLists.txt#L622) both being private links for the libcudf target. zlib is just one example of this, but this could happen for any other private target of libcudf that comes from the conda environment.

This isn't a problem for the compiler metapackages because they set a slew of compiler CLI flags, notably an `rpath-link` flag into the conda environment. I do not use these metapackages because those CLI flags set will point into the conda environment before pointing into the local build directory, which makes having both an install and a working directory a pain.

I believe the fix is either changing the `conda_env` link to be a `PUBLIC` link of the libcudf target, or adding a `conda_env` link to the tests.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.