[CMake] Linking object libraries into a Windows DLL in 3.12rc1

Deniz Bahadir dbahadir at benocs.com
Tue Jun 26 05:36:26 EDT 2018


Hi Jason,

Am 26.06.2018 um 07:45 schrieb Jason Heeris:
> 
> 
> ...
> 
> https://gitlab.com/snippets/1728169
> 
> Have I misunderstood how object library usage requirements and 
> dependencies propagate? I would appreciate any pointers on this.

Yes, you have overlooked an important detail. Only usage-requirements 
are transitive, the object-files are only propagated to directly 
dependent targets (not to indirectly dependent ones) *and only if they 
have a link/archive step* (which object-files do not have). (See: 
https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries)

That means for your particular example:

With `target_link_libraries(module1 PUBLIC common)` your OBJECT library 
"module1" gets the usage-requirements of OBJECT library "common" but not 
its object-files.
The same applies to `target_link_libraries(module2 PUBLIC module1 
common)`: OBJECT library "module2" gets the usage-requirements of OBJECT 
libraries "module1" and "common" but not their object-files.
When linking the DLL with `target_link_libraries(module2_dll module2)` 
your DLL `module2_dll` gets all usage-requirements through "module2" 
(even indirect ones from "module1" and "common") but only the 
object-files of its direct dependency (which is "module2").

You need to explicitly add "module1" and "common" to the DLL's 
target_link_library call to get their object-files, too.

When creating a static library "module2_lib" your original approach 
worked, because linking/archiving a static library works different and 
includes all object-files, even indirect ones.

Currently, there is some debate about changing the behavior of OBJECT 
libraries:
https://gitlab.kitware.com/cmake/cmake/issues/18090 
https://gitlab.kitware.com/cmake/cmake/issues/17905


HTH,
Deniz Bahadir



More information about the CMake mailing list