Link options not transitive

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Link options not transitive

krolli
Hi,

I have recently encountered what I believe might be a bug, where
INTERFACE_LINK_OPTIONS are not carried over static libraries.
Following is the simplest CMakeLists.txt that demonstrates the
problem:

cmake_minimum_required(VERSION 3.16)
project(LinkOptionsNotTransitive)
add_library(A SHARED A.cpp)
add_library(B STATIC B.cpp)
add_executable(C C.cpp)
target_link_options(A INTERFACE "/DELAYLOAD:A.dll")
target_link_libraries(B PRIVATE A)
target_link_libraries(C PRIVATE B)

I tested this with Visual Studio 2017 generator and both cmake 3.15.4
and 3.16.0-rc4, with the same result.

When inspecting generated solution, C is linking both A.lib and B.lib
(as it should), but /DELAYLOAD flag is not applied to it. If B has
PUBLIC dependency on A, then /DELAYLOAD flag is also correctly carried
over. I get the impression that target_link_options behaves as eg.
target_include_directories, which are not carried over PRIVATE
dependencies. Given that these are linker options, I would expect them
to follow same rules as target_link_libraries, which will carry over
until nearest linker invocation. Is there any reason for this
inconsistency, or is it just a bug and if so, what would be the best
way to report it?

--
Sincerely,
Martin Krošlák
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org
Reply | Threaded
Open this post in threaded view
|

Re: Link options not transitive

CMake mailing list
You should report this on the CMake issue tracker:
https://gitlab.kitware.com/cmake/cmake/issues/

On Sat, Nov 23, 2019 at 12:03 PM Martin Krošlák <[hidden email]> wrote:

>
> Hi,
>
> I have recently encountered what I believe might be a bug, where
> INTERFACE_LINK_OPTIONS are not carried over static libraries.
> Following is the simplest CMakeLists.txt that demonstrates the
> problem:
>
> cmake_minimum_required(VERSION 3.16)
> project(LinkOptionsNotTransitive)
> add_library(A SHARED A.cpp)
> add_library(B STATIC B.cpp)
> add_executable(C C.cpp)
> target_link_options(A INTERFACE "/DELAYLOAD:A.dll")
> target_link_libraries(B PRIVATE A)
> target_link_libraries(C PRIVATE B)
>
> I tested this with Visual Studio 2017 generator and both cmake 3.15.4
> and 3.16.0-rc4, with the same result.
>
> When inspecting generated solution, C is linking both A.lib and B.lib
> (as it should), but /DELAYLOAD flag is not applied to it. If B has
> PUBLIC dependency on A, then /DELAYLOAD flag is also correctly carried
> over. I get the impression that target_link_options behaves as eg.
> target_include_directories, which are not carried over PRIVATE
> dependencies. Given that these are linker options, I would expect them
> to follow same rules as target_link_libraries, which will carry over
> until nearest linker invocation. Is there any reason for this
> inconsistency, or is it just a bug and if so, what would be the best
> way to report it?
>
> --
> Sincerely,
> Martin Krošlák
> --
>
> Powered by kitware.com/cmake
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services
>
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> This mailing list is deprecated in favor of https://discourse.cmake.org
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org