[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