Regression: 3.24.0 enforces IMPORTED_LINK_DEPENDENT_LIBRARIES on import
Original title: Private shared library dependencies of exported library now checked at import
CMake 3.24 introduced a change that makes libraries in IMPORTED_LINK_DEPENDENT_LIBRARIES
turn up in the missing files list, which breaks libraries which do not explicitly import these libraries before including the target script.
The specific change seems to be this, as the entries ended up in a dummy
vector before: !7165 (diffs)
This lead to issues in OBS Studio because of the following situation:
- libobs requires w32-pthreads
- Both are built as shared libraries, obs.dll links to w32-pthreads.dll
- Both are exported as packages
- w32-pthreads ends up in
IMPORTED_LINK_DEPENDENT_LIBRARIES
for libobs. - OBS plugins are loaded at runtime (not linked) and themselves only link to obs.dll
- OBS plugins find libobs via its exported package name
We had errors in our libobsConfig.cmake
(one was running find_package
instead of find_dependency
) that lead to dependencies being found after
importing the target script:
- In CMake 3.23 this didn't lead to any issues, as
IMPORTED_LINK_DEPENDENT_LIBRARIES
didn't have any effect. - In CMake 3.24, the value(s) are now added to the target script (
# Make sure the targets which have been exported...
), but because we don't runfind_dependency
before, aFATAL_ERROR
is emitted.
The documentation for IMPORTED_LINK_DEPENDENT_LIBRARIES
states that it contains values for platforms where linked shared library dependencies are needed at link time (read: Linking to obs.dll requires the linker to be able to resolve w32-pthreads.lib as well, even though the current library does not use any symbols from it). Thus the "new" behaviour seems more correct at first glance, but also leads to sudden breakage on GitHub Actions as GitHub has been rolling out CMake 3.24 on its Windows systems.