-
Notifications
You must be signed in to change notification settings - Fork 952
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.
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
[feature] Build fails with CMake privately linking to a library with transitive dependencies #7192
Comments
I think the above captures everything that of value that conan outputs, but for completeness: consolelog.txt. Of course, I'm happy to run and gather information from any experiments you think are useful. And thank you for continuing to make conan awesome! |
Hi! Conan, as a package manager, by default removes In your case, you are building The way to go would be to import those shared libraries when running you application or, much better, to use the
This generator will populate the environment with the required variables (PATH, DYLD_LIBRARY_PATH,...) to find the shared libraries that are needed in runtime. Regarding the build process of ./test.sh
|
Good morning! Thank you for looking at this. This is definitely an issue regarding building (and neither running in the install tree, where rpaths are allowable, nor the running after install, where we bundle things together). I just tested this same procedure on my mac, it works for me there like it did for you. I think the environment difference is the compiler, so I tried it on a mac and all of the x86-64 docker images on https://github.com/conan-io/conan-docker-tools. I found that it worked on clang, xcode, gcc for centos6, and gcc for mingw. It didn't work on the other gcc docker images.
(The script for to run all the docker images, if you'd like to recreate)
|
It fails with SHARED + PRIVATE. I'm trying to figure out what happens with gcc |
Having a look to the verbose output from Private
If we remove RPATHS (
Public
I see the problem is that extra |
Thanks for looking at it! I'll refocus this, submit it to CMake's repo, and leave a link to the issue here. This does seem like a compiler-specific thing that fits in their wheelhouse, but it seemed insane to describe it without conan -- with conan it's a natural use case to have. |
Thanks! So... spread the word in the CMake realm 😄 |
@rddesmond Nice examples and problem description. I have the same problem and can reproduce it with the example you provided with CMake 3.10.2, conan version 1.34.1, and gcc version 7.5.0. What's the state of this? Did you carry the issue to the CMake repo? Could not find it there. |
@rddesmond Is the error also reproducible without conan? |
I have some links to share: I think this is a "feature" of gcc
You cannot just call a function of a private dependency...that doesn't work. What is hidden is hidden, you dont have the includes to get the definition. |
…ound for CMake shared library private linking issue. For the CMake private linking issue, see conan-io/conan#7192
See conan-io/conan#7192 for details.
…ssue. See conan-io/conan#7192 for details. virtualrunenv doesn't help for cross-compilation.
One possible solution for the problem
|
@jgsogo This is still an issue for us, to my understanding this was fixed in CMake here: In our case this is happening if an executable is linked against a lib inside the same package. And this lib has private dependencies coming from another conan package. The proposed "solution" above is not a good workaround imo. |
Hi all, I think this issue is outdated:
There are new templates in 2.0, like |
Hi @memsharded , I'm using the new CMakeDeps generator combined with cmake-conan so for Conan 1.x I'm using state-of-the-art approaches. Forwarding to Conan 2.0 isn't really helping as we will not move there until a solution is available for cmake-conan. But I can try to setup a recent example. |
This is the thing, the issue reported above, with the code reported above is using the previous integrations, which can have a very high effect in how things are managed. I can see that with the new integrations it is still an issue, but it can be a bit confusing mixing both in the same ticket. Also, the fact that cmake-conan is not ready for 2.0 doesn't mean that Conan 2.0 new graph model couldn't be a solution for this issue, as it is not really related to the linking issue. In any case, I don't think that 2.0 will fix the issue, but we should probably test first in 2.0 with the new integrations, as that would be a bit easier to prioritize. |
@memsharded I've setup a small example. If this is not related to the topic of the discussion above, we can also move this into a new issue. The relationship is as follows ("->" == "depends on"): Build via:
This is failing with:
The error is gone once you link libB PUBLIC against libA. I was wondering whether this is related to this issue, but I might be wrong.
|
Yes, moved your comment to: #13302 |
Any updates on this issue? |
@576347172 Have you seen the comments in #13302?, specifically #13302 (comment) Using If not, please create a new ticket with details to reproduce, it might be a different thing. |
Check conan-io/conan#7192 for more information.
This falls somewhere between a bug, a feature request, and a comment for the various issues about RPATH handling. It's also troublesome in CMake alone, where their #19556 and #19707 are similar (though involving shared and static libraries, respectively, not imported ones).
When using the cmake generator and linking an application that privately consumes a library in its build path, the library's transitive dependencies cannot be found at link time (but it's okay at runtime). The minimal chain (where
app
andC
are in the same project, andB
andA
are independent conan projects with emptyRPATH
s) is:In the build tree, the app should be able to link and run. In the install tree,
libraryB
andlibraryA
needs to be in a known location, but that's a different story.Environment Details (include every applicable attribute)
Steps to reproduce
private-transitive-issue.tar.gz contains a small example. Untar and run
./test.sh
.This
conan create
sproj_A
(libprojA
),proj_B
(libprojB
), andproj_C
(libprojC
andapp
), where each calls a function in the one before it (app:main
->libprojC:hello_C
->libprojB:hello_B
->libprojA:hello_A
). It will fail during the linking of the app. All libraries are privately linked from CMake's perspective.If you build it with workaround 2 below, it will run in the build tree, because the
RPATH
oflibprojC
will include the paths tolibprojA
andlibprojB
.Workarounds
libprojC
tolibprojB
publicly (switch the commented line in "C/src/CMakelists.txt" from lines 9 to 8).-Wl,--unresolved-symbols=ignore-in-shared-libs
(uncomment "C/src/CMakelists.txt" line 13)The text was updated successfully, but these errors were encountered: