Thiago, I haven’t see the double entry pattern that you mention below. However, you might want to tell CMake to embed a BUILD_RPATH in your libraries. This should get around the issue of manually setting LD_LIBRARY_PATH.
https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath -kt From: CMake <cmake-boun...@cmake.org> On Behalf Of Thiago Crepaldi Sent: Thursday, February 14, 2019 12:43 AM To: cmake@cmake.org Subject: [CMake] Multiple occurrences of a library on linux (ldd) Hello all, After reading CMake Cookbook I have written my first "complex" CMake build script based on the superbuild pattern. I am excited to heave a better understanding on CMake, but I definitely will learn much more from experience and your kind help. In summary, the standalone google test application `standalone_gtests` publicly links to `libdatareader.so` and to pytorch libraries (`libc10.so`,`libcafee2.so`, `libtorch.so`). `libdatareader.so` also publicly links to pytorch libraries (I have a theoretical question on why `standalone_gtests` had to link to pytorch libraries if `libdatareader.so` already did, but that can wait). Compilation finishes successfully, but when I try to run `standalone_gtests`, it aborts because it cant find `libc10.so`. After executing `ldd standalone_gtests`, the weird result was that there were two entries for `libc10.so`. The first one maps to "not found" while the second had the correct path to the library. `libcaffe2.so`, which is also a pytorch library, has a single occurrence with full path. If I add the (...)/pytorch_external/(...) (see ldd output below) path to LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if possible. `ldd ./subprojects/Build/datareaders_core_test/standalone_gtests libdatareader.so => /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so libcaffe2.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so libc10.so => not found libc10.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so (...)` Have anyone seen multiple entries for the same library on ldd before? Why is that? Is it because `standalone_gtests` links to libc10.so and to `libdatareader.so`, which in turn also links to `libc10.so`? Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the correct path). I run the same build on my Mac and everything works fine, so that is confined to linux environment. I have destroyed my conda environment and performed multiple clean builds in the process and no luck :( Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and `sudo rm /etc/ld.so.cache`, but that doesn't fix it. Any ideas? best regards, Thiago
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
