Transitive behavior of target_link_libraries between shared/static

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Transitive behavior of target_link_libraries between shared/static

Robert Dailey-2
Suppose I have the following:

```
add_library( A STATIC ${files} )

add_library( B SHARED ${more_files} )
target_link_libraries( B PUBLIC A )

add_library( C STATIC ${even_more_files} )
target_link_libraries( C PUBLIC B )


add_executable( D ${exe_files} )
target_link_libraries( D PRIVATE C )
```

Does the linker command for target `D` ever see target A's static link
library? I'm hoping the only thing the linker gets is `libB.so` and
`libC.a`, without `libA.a`.

It seems like A to everyone outside of B should just be a set of
public include directories and compile definitions, since the link
file aspect of it should be hidden across shared library boundaries.
Hoping someone can explain how this works. I want to make sure static
libs sitting behind shared libs in the dependency tree do not get
exposed.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transitive behavior of target_link_libraries between shared/static

Eric Noulard


2017-07-17 17:31 GMT+02:00 Robert Dailey <[hidden email]>:
Suppose I have the following:

```
add_library( A STATIC ${files} )

add_library( B SHARED ${more_files} )
target_link_libraries( B PUBLIC A )

add_library( C STATIC ${even_more_files} )
target_link_libraries( C PUBLIC B )


add_executable( D ${exe_files} )
target_link_libraries( D PRIVATE C )
```

Does the linker command for target `D` ever see target A's static link
library? I'm hoping the only thing the linker gets is `libB.so` and
`libC.a`, without `libA.a`.

I guess it does otherwise you may be missing symbols.
As explain by Peter some time ago:
when you
target_link_libraries( B PUBLIC A )

with A being STATIC you do not really link A into B (which is shared in your example)
but you add A as a PUBLIC item of the link interface of B such that when actual linking
occurs if you build an executable linked to B then A is automagically brought to the link step. 

More info on that topic by Craig:


It seems like A to everyone outside of B should just be a set of
public include directories and compile definitions, since the link
file aspect of it should be hidden across shared library boundaries.

No it is not, because the binary object inside A are NOT embedded into B.
If you want that then you need to make A an OBJECT library and not a STATIC library.

 
Hoping someone can explain how this works. I want to make sure static
libs sitting behind shared libs in the dependency tree do not get
exposed.

My understanding is that you cannot do what you want with static lib.
You can do that with OBJECT lib though.
Knowing that you cannot use target_link_libraries with OBJECT lib:

Hope this helps.

--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transitive behavior of target_link_libraries between shared/static

Hendrik Sattler


Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard <[hidden email]>:

>2017-07-17 17:31 GMT+02:00 Robert Dailey <[hidden email]>:
>
>> Suppose I have the following:
>>
>> ```
>> add_library( A STATIC ${files} )
>>
>> add_library( B SHARED ${more_files} )
>> target_link_libraries( B PUBLIC A )
>>
>> add_library( C STATIC ${even_more_files} )
>> target_link_libraries( C PUBLIC B )
>>
>>
>> add_executable( D ${exe_files} )
>> target_link_libraries( D PRIVATE C )
>> ```
>>
>> Does the linker command for target `D` ever see target A's static
>link
>> library? I'm hoping the only thing the linker gets is `libB.so` and
>> `libC.a`, without `libA.a`.
>>
>
>I guess it does otherwise you may be missing symbols.
>As explain by Peter some time ago:
>  https://cmake.org/pipermail/cmake/2017-April/065347.html
>when you
>target_link_libraries( B PUBLIC A )
>
>with A being STATIC you do not really link A into B (which is shared in
>your example)

You confused PUBLIC and INTERFACE in your response.
target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols needed by B.

The link to the old post has it all right.

HS


--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transitive behavior of target_link_libraries between shared/static

Robert Dailey-2
Maybe I'm missing something here, but that linked article doesn't
really address my specific case. And his definition is technically
correct, as long as CMake is smart enough to handle the case where
(again in my example) A does not need to be explicitly linked to D
because they were already linked into B (since it's a shared library).
Link dependencies of B should be firewalled to downstream targets.
However, include dependencies for example may be needed downstream
since B's public headers may require them.

I could create a sandbox using my example to verify the behavior, but
i thought it would be quicker to ask here to see if anyone knew.

On Tue, Jul 18, 2017 at 12:15 PM, Hendrik Sattler
<[hidden email]> wrote:

>
>
> Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard <[hidden email]>:
>>2017-07-17 17:31 GMT+02:00 Robert Dailey <[hidden email]>:
>>
>>> Suppose I have the following:
>>>
>>> ```
>>> add_library( A STATIC ${files} )
>>>
>>> add_library( B SHARED ${more_files} )
>>> target_link_libraries( B PUBLIC A )
>>>
>>> add_library( C STATIC ${even_more_files} )
>>> target_link_libraries( C PUBLIC B )
>>>
>>>
>>> add_executable( D ${exe_files} )
>>> target_link_libraries( D PRIVATE C )
>>> ```
>>>
>>> Does the linker command for target `D` ever see target A's static
>>link
>>> library? I'm hoping the only thing the linker gets is `libB.so` and
>>> `libC.a`, without `libA.a`.
>>>
>>
>>I guess it does otherwise you may be missing symbols.
>>As explain by Peter some time ago:
>>  https://cmake.org/pipermail/cmake/2017-April/065347.html
>>when you
>>target_link_libraries( B PUBLIC A )
>>
>>with A being STATIC you do not really link A into B (which is shared in
>>your example)
>
> You confused PUBLIC and INTERFACE in your response.
> target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols needed by B.
>
> The link to the old post has it all right.
>
> HS
>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transitive behavior of target_link_libraries between shared/static

Eric Noulard
In reply to this post by Hendrik Sattler


2017-07-18 19:15 GMT+02:00 Hendrik Sattler <[hidden email]>:


Am 18. Juli 2017 18:02:40 MESZ schrieb Eric Noulard <[hidden email]>:
>2017-07-17 17:31 GMT+02:00 Robert Dailey <[hidden email]>:
>
>> Suppose I have the following:
>>
>> ```
>> add_library( A STATIC ${files} )
>>
>> add_library( B SHARED ${more_files} )
>> target_link_libraries( B PUBLIC A )
>>
>> add_library( C STATIC ${even_more_files} )
>> target_link_libraries( C PUBLIC B )
>>
>>
>> add_executable( D ${exe_files} )
>> target_link_libraries( D PRIVATE C )
>> ```
>>
>> Does the linker command for target `D` ever see target A's static
>link
>> library? I'm hoping the only thing the linker gets is `libB.so` and
>> `libC.a`, without `libA.a`.
>>
>
>I guess it does otherwise you may be missing symbols.
>As explain by Peter some time ago:
https://cmake.org/pipermail/cmake/2017-April/065347.html
>when you
>target_link_libraries( B PUBLIC A )
>
>with A being STATIC you do not really link A into B (which is shared in
>your example)

You confused PUBLIC and INTERFACE in your response.
target_link_libraries( B PUBLIC A ) DOES link A into B but only the symbols needed by B.

The link to the old post has it all right.


Thanks for the clarification Hendrik,

The thing I wasn't sure is that when B is shared and A is static

target_link_libraries(B PUBLIC A) or even
target_link_libraries(B PRIVATE A)

was effectively putting objects from A needed by B into B.

My use case was when B and A were STATIC.

I'll try an example in order to have concrete example at hand.

--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Loading...