CMake install tests failing when using dependend libraries

[Flamefire]

I tried Boost.CI on Boost.Locale where a test binary links against Boost::locale which privately links against Boost::thread.

This fails on some platforms, e.g. Ubuntu 20.04 as the Boost.Thread library cannot be found. See e.g. https://github.com/Flamefire/locale/runs/6047122561?check_suite_focus=true

/home/runner/work/locale/boost-root/libs/locale/test/cmake_test/build_cmake_install_test/main: error while loading shared libraries: libboost_thread.so.1.80.0: cannot open shared object file: No such file or directory

But the library is installed:

Installing: /home/runner/.local/lib/libboost_thread.so.1.80.0

Also on Windows the test also fails likely due to the same reason:

1/1 Test #1: main .............................Exit code 0xc0000135
***Exception: 0.01 sec

It looks like we'd need to add the library install path to LD_LIBRARY_PATH on Linux and something similar on Windows (PATH?) although I feel like this is something which should be handled by CMake but isn't.

Would be good if we could fix that "by default" in the Boost.CI samples.

@pdimov Any ideas?

[pdimov]

An RPATH issue, I suppose. Or rather, a RUNPATH issue. RPATH propagates from the executable to the shared libraries, but RUNPATH does not. And there was also something with the Ubuntu linker being patched to use RUNPATH by default, as opposed to the usual RPATH by default.

[pdimov]

On Windows, the DLLs have to be in the search path, and there's nothing CMake can do about it, as there's no RPATH equivalent there (as far as I know).

[Flamefire]

I was able to fix that for the subdir tests using CMAKE_RUNTIME_OUTPUT_DIRECTORY (place exe and dll into same folder)

However the install tests are still failing on Ubuntu and Windows.

[Flamefire]

So we probably need to set LD_LIBRARY_PATH (Linux) or PATH (Windows) for the CI tests.
To test this in this repo: @pdimov You likely still have that dependency graph. Which Boost library could we use in Boost.CI which has a shared library and is as small as possible/fast to build? I.e. a small one without dependencies would be best.

[pdimov]

I think that Timer is a good Guinea pig because it uses Chrono. Interestingly, the only place I see where a path is set is here: https://github.com/boostorg/timer/blob/9ee4c9cd9dec4f4ab5c38ffb9cb9978427916ee0/.github/workflows/ci.yml#L323

The rest of GHA and Appveyor seems to not need it for some reason.

[Flamefire]

I think you misunderstood: I already have Boost.Locale to "play with". I wanted to fix and test this in Boost.CI for others to benefit. I.e. I need a shared Boost library which should be very small, i.e. few dependencies and fast to build which I can add here: https://github.com/boostorg/boost-ci/blob/master/CMakeLists.txt

So basically recreate the issue using Boost::boost_ci by making that a compiled library depending on some other shared Boost library.

The rest of GHA and Appveyor seems to not need it for some reason.

That is the only place where the described situation appears: Consume the installed Boost library(ies).
With some sub-cases of that as follows:

Works:

• static builds
• shared builds with no shared lib dependencies on Linux

Doesn't work (needs the path-setting):

• shared builds with shared lib dependencies
• shared builds on Windows

For the case(s) where the tests are build alongside Boost it works because all binaries (executables and DLLs) are put into the same folder which is in the "search path" on all platforms.

[pdimov]

As the dependency you can use Chrono (like Timer does) or e.g. Atomic. Chrono is more stable because it's in maintenance mode.

[pdimov]

For the case(s) where the tests are build alongside Boost it works because all binaries (executables and DLLs) are put into the same folder which is in the "search path" on all platforms.

Another possible reason for things working except in install scenarios is that both CMake and b2 clear the rpath when installing shared libraries.

[Flamefire]

As the dependency you can use Chrono (like Timer does) or e.g. Atomic. Chrono is more stable because it's in maintenance mode.

I was hoping for something with less dependencies. Chrono has 15 direct dependencies and Atomic has 8. All of them need to be cloned, which takes CI time. But might use Chrono anyway...

Another possible reason for things working except in install scenarios is that both CMake and b2 clear the rpath when installing shared libraries.

Possible, but mostly it is the usage of CMAKE_RUNTIME_OUTPUT_DIRECTORY as I noticed during the subdir test (i.e. add_subdirectory the library and its dependencies)

[pdimov]

Nothing lighter than Atomic in https://pdimov.github.io/boostdep-report/develop/module-weights.html. My go-to compiled library was System but it's only nominally compiled now so it can't be used for testing.

Possible, but mostly it is the usage of CMAKE_RUNTIME_OUTPUT_DIRECTORY as I noticed during the subdir test (i.e. add_subdirectory the library and its dependencies)

I don't set the output directory in https://github.com/boostorg/timer/blob/develop/test/cmake_subdir_test/CMakeLists.txt though.

[Flamefire]

I don't set the output directory in https://github.com/boostorg/timer/blob/develop/test/cmake_subdir_test/CMakeLists.txt though.

But it doesn't has Windows tests and the failures on Ubuntu might be something else or maybe something has changed since the last run.