abseil/20180223 - Wrong linkage order

[r-darwish]

Description of Problem, Request, or Question

Trying to build this app caused the following linkage command:

/usr/bin/c++ -std=c++11 -rdynamic CMakeFiles/atest.dir/main.cpp.o -o bin/atest -L/home/roeyd/.conan/data/abseil/20180223/bincrafters/stable/package/d2b9b1e5dc4f75ac827291c9bda9970b49137f53/lib -L/home/roeyd/.conan/data/cctz/2.2/bincrafters/stable/package/b60023f9fa06321277cb53d223d0048027c27904/lib -Wl,-rpath,/home/roeyd/.conan/data/abseil/20180223/bincrafters/stable/package/d2b9b1e5dc4f75ac827291c9bda9970b49137f53/lib:/home/roeyd/.conan/data/cctz/2.2/bincrafters/stable/package/b60023f9fa06321277cb53d223d0048027c27904/lib -labsl_algorithm -labsl_container -labsl_memory -labsl_dynamic_annotations -labsl_spinlock_wait -labsl_meta -labsl_utility -labsl_stack_consumption -labsl_throw_delegate -labsl_span -labsl_bad_optional_access -labsl_any -ltest_instance_tracker_lib -labsl_int128 -labsl_numeric -labsl_stacktrace -labsl_malloc_internal -labsl_base -labsl_leak_check -labsl_bad_any_cast -labsl_optional -labsl_malloc_extension -labsl_debugging -labsl_time -labsl_strings -labsl_synchronization -lpthread -lcctz 

Which caused the following error:

sysinfo.cc:(.text+0x452): undefined reference to `AbslInternalSpinLockWake'

This is due to the fact that -labsl_spinlock_wait, which contains AbslInternalSpinLockWake, comes before -labsl_base, which depends on it. As stated here, the order should be reversed. Running the same command when moving -labsl_spinlock_wait to end of the command seems to work.

The current implementation of package_info calls tools.collect_libs, which in turn calls os.listdir, which does not guarantee any order, so the problem reproduces randomly.

Package Details (Include if Applicable)

• Package Name/Version: abseil/20180223
• Operating System: Arch Linux
• Compiler+version: gcc-7.3

Steps to reproduce (Include if Applicable)

Compile the program above.

[solvingj]

@r-darwish Are we able to fix the link order manually now that we know of the issue?

[bschindler]

@solvingj I got notified of this issue as I ran into a similar issue. In my case, it was a package which attempted to install some system libraries and then link against them. But since the library was only added as if it was part of the package, conan did not know that there was a dependency between the two. As soon another package (or some other command) added a link dependency to that system library, cmake sometimes reordered the link order which made compilation break.

So essentially, this is an issue for every package doing something like:

installer.install("%s%s" % ("somelib", arch_suffix))
... 
self.cpp_info.libs = ['package_lib' 'somelib']

All it takes that this potentially breaks is:

target_link_library(mytarget PUBLIC CONAN_PKG::package_lib)
target_link_library(mytarget somelib)

cmake (or any other build system) has no knowledge that package_lib depends on somelib which gives potential for link failures

[drrlvn]

Unless I'm missing something, it looks like abseil's CMakeLists.txt correctly specifies that absl_base depends on absl_spinlock_wait here. If so then this bug should not happen regardless of the order returned by tools.collect_libs.

[solvingj]

Did anyone involved make any headway with this? @drrlvn or @bschindler ?

[drrlvn]

Both @r-darwish and I had babies very recently so we're not doing much work, it'll take us a bit to get back. Sorry.

[SSE4]

@r-darwish changes are in testing/20180223 branch, please give a try

[drrlvn]

The testing branch works for me, thanks!

[SSE4]

confirmed as fixed, closing

[SimonEbner]

@bschindler sorry for hijacking the topic but I do have exactly this situation that you mention

installer.install("%s%s" % ("somelib", arch_suffix))
... 
self.cpp_info.libs = ['package_lib' 'somelib']

Is there any solution in conan how to handle this situation? In my specific case I am talking about openssl with libcryto that has a dependency on libdl.