[bug] conan 2.x: linking against a shared lib with private shared dependencies fails on Linux (again) #13560
Comments
|
Mmmhh actually it may be an issue of libzipp recipe instead. I see that linker errors occur while linking |
|
I re-open because looking at CMakeLists, it shouldn't have failed anyway. libzippp target builds fine, but when this target is linked into libzippp_shared_test, I guess something is not properly defined in libzip::zip target and therefore CMake doesn't understand that it must define |
|
I have just tested and it works. There might be something else you have on your side that you are not reporting, for example |
|
Indeed, my global.conf is: |
|
@memsharded there is a good chance that you can't reproduce this issue if the same openssl so version is installed on your Linux distribution. |
|
I see a similar issue in a recipe not merged yet in conan center. On Linux with this profile: You have to ckeckout first conan-io/conan-center-index#16355 and call You should see these errors (since it's related to link errors to log |
|
I suspect the same issue in conan-io/conan-center-index#16208 (comment) |
And indeed build of OpenMVG executables fails in c3i for "Linux all shared" because transitive shared libs don't seem to be added to -rpath-link: https://c3i.jfrog.io/c3i/misc-v2/logs/pr/16356/13-linux-gcc/openmvg/2.0//420b80fc6515bf813bb6636821a1a154a4010d07-build.txt The common logic I see in these libraries is that:
|
|
Same issue in test package of opencv: conan-io/conan-center-index#16678 (comment) |
|
@memsharded any chance that conan can track this issue? We have several repro cases in conan-center: opencv & openmvg. opencv recipe has an ugly workaround (protobuf libs are marked transitive, while they should not be). |
|
I'd need some updated repro case, please, it seems the linked ones are already closed or outdated. Also, investigating these things over ConanCenter recipes takes a lot more of time, that we usually don't have. Is not that we don't want to track it, is simply that we don't have more hours in the day, so they fall through the cracks. The chance to be able to address issues that are reported with simple |
|
You can't reproduce with |
|
@memsharded Here is a minimal reproducible example: https://github.com/SpaceIm/conan_issue_13560. Instructions in README (3 |
|
Thanks for putting the repro case together. I have checked it, and it seems this would work changing this: --- a/libC_issue13560/CMakeLists.txt
+++ b/libC_issue13560/CMakeLists.txt
@@ -4,7 +4,7 @@ project(libC_issue13560 LANGUAGES CXX)
find_package(libb_issue13560 REQUIRED CONFIG)
add_library(libC_issue13560 libC_issue13560.cpp)
-target_link_libraries(libC_issue13560 PRIVATE libb_issue13560::libb_issue13560)
+target_link_libraries(libC_issue13560 PUBLIC libb_issue13560::libb_issue13560)
add_executable(execC_issue_13560 execC_issue13560.cpp)
target_link_libraries(execC_issue_13560 PRIVATE libC_issue13560It is not expected that you can link the executable with the dependencies correctly if you make libC->libB PRIVATE. |
|
I've pushed a new commit (SpaceIm/conan_issue_13560@c43456f) which add an option in order to package flavors of libs with state of the art CMake config files, Here is the relevant content which might differ from files generated by CMakeDeps. Specifically the libA_issue13560Targets-release.cmake #----------------------------------------------------------------
# Generated CMake target import file for configuration "Release".
#----------------------------------------------------------------
# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)
# Import target "libA_issue13560::libA_issue13560" for configuration "Release"
set_property(TARGET libA_issue13560::libA_issue13560 APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(libA_issue13560::libA_issue13560 PROPERTIES
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/liblibA_issue13560.so"
IMPORTED_SONAME_RELEASE "liblibA_issue13560.so"
)
list(APPEND _cmake_import_check_targets libA_issue13560::libA_issue13560 )
list(APPEND _cmake_import_check_files_for_libA_issue13560::libA_issue13560 "${_IMPORT_PREFIX}/lib/liblibA_issue13560.so" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)libB_issue13560Targets-release.cmake #----------------------------------------------------------------
# Generated CMake target import file for configuration "Release".
#----------------------------------------------------------------
# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)
# Import target "libB_issue13560::libB_issue13560" for configuration "Release"
set_property(TARGET libB_issue13560::libB_issue13560 APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(libB_issue13560::libB_issue13560 PROPERTIES
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE "libA_issue13560::libA_issue13560"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/liblibB_issue13560.so"
IMPORTED_SONAME_RELEASE "liblibB_issue13560.so"
)
list(APPEND _cmake_import_check_targets libB_issue13560::libB_issue13560 )
list(APPEND _cmake_import_check_files_for_libB_issue13560::libB_issue13560 "${_IMPORT_PREFIX}/lib/liblibB_issue13560.so" )
# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION) |
|
It is a known issue that Conan doesn't have the full information to define IMPORTED things in As there is a relatively easy workaround defining the |
|
Ok, thanks.
It's not an easy workaround when you have to patch CML forever. An easy workaround is to inject VirtualRunEnv into build scope. |
|
Here is a summary I made, hoping it can help to improve CMake config fileContext
Matrix
Results
|
|
@memsharded It may be a coincidence, but another similarity is that dependencies which seem to trigger this issue in some recipes depending on them, have |
* add package_type * bump freetype & libpng * avoid patch in 1.10 * add msdfgen/1.11 * inject BUILD_SHARED_LIBS as cache_variables * simplify patching strategy of previous versions * restore find_package module freetype * remove pdb files * Revert "restore find_package module freetype" This reverts commit d678393. * workaround for conan-io/conan#13560 * bump freetype * less verbose package_info() * Update recipes/msdfgen/all/conanfile.py Co-authored-by: Matthieu Darbois <mayeut@users.noreply.github.com> --------- Co-authored-by: Rubén Rincón Blanco <git@rinconblanco.es> Co-authored-by: Matthieu Darbois <mayeut@users.noreply.github.com>
|
I can confirm that the newer/still experimental CMakeDeps fixes this issue and we've managed to isolate and reproduce it. Based on the original issue reported in the issue description: This is a bit nuanced, the linker is not failing to a create the This is due to this: At this point, the Other instances of CMake not adding The issue only happens when using the GNU bfd Linker (the default on most Linuxes) - if gold, lld or mold are used, this is unlikely to be a problem Possible workarounds for "older" CMakeDeps:
EIther way this should be preferred over tweaking any build scripts to use a public instead of private dependency. The underlying cause is indeed a lack of the |
Environment details
Steps to reproduce
conan install --requires="libzippp/6.0-1.9.2" -o "*:shared=True" -b missingLogs
build log
related to #13000
If you dig into libzippp recipe, recipe of its dependency libzip, their upstream CMakeLists and how they are patched, you'll see that libzippp properly links to
libzip::ziptarget defined in libzip recipe, and thatopenssl::cryptoconan component of openssl recipe is properly appended torequiresof thislibzip::_libzipconan component inpackage_info()of libzip. Still, openssl crypto is missing in-rpath-linkwhen linker tries to create libzippp shared lib.The text was updated successfully, but these errors were encountered: