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
- 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_LIBRARIESdidn'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 run
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.