Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add test for shared libraries with dependencies #158

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

Add test for shared libraries with dependencies #158

wants to merge 5 commits into from

Conversation

Flamefire
Copy link
Collaborator

Convert the header-only library to a compiled library which additionally depends (privately) on another compiled library (Boost.Atomic chosen as it has few other dependencies).
This reproduces the runtime link failure of #155 when compiling shared libraries.

@Flamefire Flamefire changed the title Add test (and fix) for shared libraries with dependencies Add test for shared libraries with dependencies Apr 28, 2022
@Flamefire
Copy link
Collaborator Author

Flamefire commented Apr 28, 2022 •
edited
Loading

Hm, for some reason it succeeds on Ubuntu while it should not. See e.g. https://github.com/Flamefire/locale/runs/6047203575?check_suite_focus=true where Boost.Locale links privately against Boost.Thread and then fails to find it (likely due to cleared RPath)
I would say that here it is the same situation with Boost.Boost-CI linking privately against Boost.Atomic.

@pdimov Any idea what I'm missing?

@pdimov
Copy link
Member

pdimov commented Apr 28, 2022

I don't know. The only thing I notice is that

-- Installing: /home/runner/.local/lib/libboost_atomic.so.1.80.0
-- Installing: /home/runner/.local/lib/libboost_atomic.so
...
-- Installing: /home/runner/.local/lib/libboost_boost_ci.so.1.80.0
-- Set runtime path of "/home/runner/.local/lib/libboost_boost_ci.so.1.80.0" to ""
-- Installing: /home/runner/.local/lib/libboost_boost_ci.so

the runtime path of boost-ci is cleared while atomic's is not, for some reason. Why, I've no idea. There should be no difference.

@Flamefire
Copy link
Collaborator Author

the runtime path of boost-ci is cleared while atomic's is not, for some reason. Why, I've no idea. There should be no difference.

Possibly because atomic doesn't have any dynamic library deps so no rpath. Same for the Boost.Locale build: Clearing Locale and Thread but not Atomic. Doesn't explain the difference though -.- Maybe because no exported function from Atomic is actually used?

@pdimov
Copy link
Member

pdimov commented Apr 28, 2022

Maybe because no exported function from Atomic is actually used?

Oh yes, that might well be the reason. :-)

@Flamefire
Copy link
Collaborator Author

Hm, atomic is mostly header-only it seems. I can't really find a (public) way to call one of the few library functions on all platforms.

@Flamefire Flamefire force-pushed the shared_build_test branch from 033084a to 2c9a822 Compare May 2, 2022 14:49
@Flamefire
Copy link
Collaborator Author

Flamefire commented May 2, 2022 •
edited
Loading

Ok now it fails as expected for All shared builds of the install test

@Flamefire
Make the test library a compiled library
7e8379a 
Convert the header-only library to a compiled library which additionally depends (privately) on another compiled library (Boost.Atomic chosen as it has few other dependencies).
This reproduces the runtime link failure of #155 when compiling shared libraries.
@Flamefire Flamefire force-pushed the shared_build_test branch from 2c9a822 to 7e8379a Compare May 21, 2022 08:08
Flamefire added 4 commits May 21, 2022 11:03
@Flamefire
Fix dynamic CMake subdir tests on Windows
2a23623 
On Windows DLLs need to be either in PATH or in the same folder as the executable.
The latter is easy to achieve by setting CMAKE_RUNTIME_OUTPUT_DIRECTORY
which puts all runtime files (exe, dll, so) into the specified folder.
So do that.
@Flamefire
Use a variable to store the install path for the CMake test
2efd425 
Avoids the repetition.
Use a subfolder of /tmp which is unlikely to exist.
Additionally using $HOME may cause trouble due to path translation on Windows-Bash
@Flamefire
Fix dynamic CMake install tests
96dab18 
To find dynamic libraries which are only indirect dependencies the
variable LD_LIBRARY_PATH (Linux) or PATH (Windows) must contain the
folder of the binaries.
@Flamefire
Merge pull request #162 from boostorg/shared_build_fix
bc54f0e 
Fix CMake tests when using dynamic libraries
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Flamefire @pdimov