Reduced control over linker command line with shared libraries
Due to the deduplication of shared library references in the linker command line, the users looses control over the order of references in the linker command line. This is problematic on Windows, where the argument order of shared libraries on the linker command line defines the dll loading order.
Example
project(Test)
add_executable(target_a source.cpp)
add_library(target_b SHARED source.cpp)
add_library(target_c SHARED source.cpp)
target_link_libraries(target_b target_c)
target_link_libraries(target_a target_c target_b)
Output
Using Ninja generator on Windows. Similar results with Ninja on linux and Visual Studio on Windows:
build target_a.exe: CXX_EXECUTABLE_LINKER__target_a_Debug CMakeFiles/target_a.dir/source.cpp.obj | target_b.lib target_c.lib || target_b.dll target_c.dll
LINK_LIBRARIES = target_b.lib target_c.lib -lkernel32 -luser32 -lgdi32 ...
The libraries are not listed in the order specified in the link_libraries call. I assume the problem is this:
- target_c is appended to the end of linker command line because target_b depends on it.
- The references to shared libraries on the linker command line are deduplicated, with later references taking preference. This removes the original
target_c
reference that the user has specified.
Edited by Christian Fersch