Transitive linking and static libraries

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

Transitive linking and static libraries

James Bigler
Is it possible to stop known static libraries from being carried through shared libraries?

add_library(mystatic1 STATIC ...)
add_library(mystatic2 STATIC ...)
add_library(myshared SHARED ...)
target_link_libraries(myshared mystatic1 mystatic2)
add_executable(myexe)
target_link_libraries(myexe myshared)

Once a shared library is created, all the information about what libraries are needed should be encoded in the shared library.  In addition if myexe links against only myshared then only the symbols being exported by myshared should be visible to myexe.

I'm seeing problems where symbols from mystatic1 are being seen by myexe, when myexe should only be seeing symbols from myshared.  This is because CMake links myshared, mystatic1, and mystatic2 to myexe all in the same link line.

James

--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Matthew Woehlke-2
On 2013-10-16 14:05, James Bigler wrote:
> Is it possible to stop known static libraries from being carried through
> shared libraries?

Did you try using 'LINK_PRIVATE' in your target_link_libraries?

--
Matthew

--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Robert Maynard
In reply to this post by James Bigler
Have you tried using the LINK_PRIVATE signature to target link libraries?

On Wed, Oct 16, 2013 at 2:05 PM, James Bigler <[hidden email]> wrote:

> Is it possible to stop known static libraries from being carried through
> shared libraries?
>
> add_library(mystatic1 STATIC ...)
> add_library(mystatic2 STATIC ...)
> add_library(myshared SHARED ...)
> target_link_libraries(myshared mystatic1 mystatic2)
> add_executable(myexe)
> target_link_libraries(myexe myshared)
>
> Once a shared library is created, all the information about what libraries
> are needed should be encoded in the shared library.  In addition if myexe
> links against only myshared then only the symbols being exported by myshared
> should be visible to myexe.
>
> I'm seeing problems where symbols from mystatic1 are being seen by myexe,
> when myexe should only be seeing symbols from myshared.  This is because
> CMake links myshared, mystatic1, and mystatic2 to myexe all in the same link
> line.
>
> James
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

James Bigler
This seems to do what I want.

Is there a version of this that works for IMPORTED targets.

There's IMPORTED_LINK_INTERFACE_LIBRARIES, but I'm not sure how to make them private for static libraries.

Thanks,
James


On Wed, Oct 16, 2013 at 12:17 PM, Robert Maynard <[hidden email]> wrote:
Have you tried using the LINK_PRIVATE signature to target link libraries?

On Wed, Oct 16, 2013 at 2:05 PM, James Bigler <[hidden email]> wrote:
> Is it possible to stop known static libraries from being carried through
> shared libraries?
>
> add_library(mystatic1 STATIC ...)
> add_library(mystatic2 STATIC ...)
> add_library(myshared SHARED ...)
> target_link_libraries(myshared mystatic1 mystatic2)
> add_executable(myexe)
> target_link_libraries(myexe myshared)
>
> Once a shared library is created, all the information about what libraries
> are needed should be encoded in the shared library.  In addition if myexe
> links against only myshared then only the symbols being exported by myshared
> should be visible to myexe.
>
> I'm seeing problems where symbols from mystatic1 are being seen by myexe,
> when myexe should only be seeing symbols from myshared.  This is because
> CMake links myshared, mystatic1, and mystatic2 to myexe all in the same link
> line.
>
> James
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake


--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Giordano Khouri
In reply to this post by James Bigler

The static libraries must be compiled with -fvisibility=hidden. Symbols with default visibility are marked as “public” and will leak from a shared library. With hidden visibility, they symbols are marked as “private extern”, allowing you to link with them, but not allowing them to leak from a shared library. Any time that shared libraries are involved, you will want hidden visibility and mark your public API functions with default visibility.

 



Khouri Giordano
Software Technology Researcher
Nikon Inc.
1300 Walt Whitman Road
Melville NY 11747-3064
Office: 631-547-4335 Fax: 631-547-0361
[hidden email]

 

www.nikonusa.com

 

 



From: [hidden email] [mailto:[hidden email]] On Behalf Of James Bigler
Sent: Wednesday, October 16, 2013 2:06 PM
To: [hidden email]
Subject: [CMake] Transitive linking and static libraries

 

Is it possible to stop known static libraries from being carried through shared libraries?

 

add_library(mystatic1 STATIC ...)

add_library(mystatic2 STATIC ...)

add_library(myshared SHARED ...)

target_link_libraries(myshared mystatic1 mystatic2)

add_executable(myexe)

target_link_libraries(myexe myshared)

 

Once a shared library is created, all the information about what libraries are needed should be encoded in the shared library.  In addition if myexe links against only myshared then only the symbols being exported by myshared should be visible to myexe.

 

I'm seeing problems where symbols from mystatic1 are being seen by myexe, when myexe should only be seeing symbols from myshared.  This is because CMake links myshared, mystatic1, and mystatic2 to myexe all in the same link line.

 

James



CONFIDENTIAL:
This e-mail including any attachments is intended only for the party or parties to whom it is addressed and may contain information which is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, copying, or printing of any information contained in or attached to this e-mail is STRICTLY PROHIBITED and may constitute a breach of confidentiality and/or privilege. If you have received this e-mail in error, please notify immediately the sender by reply e-mail and then delete this e-mail and any attachments in their entirety from your system. Thank you. This e-mail message including any attachments is believed to be free of any viruses; however, it is the sole responsibility of the recipient to ensure that it is virus free, and Nikon does not accept any responsibility for any loss, disruption or damage to your data or computer system which may occur in connection with this e-mail including any attachments.


--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

James Bigler
On Wed, Oct 16, 2013 at 1:34 PM, Giordano Khouri <[hidden email]> wrote:

The static libraries must be compiled with -fvisibility=hidden. Symbols with default visibility are marked as “public” and will leak from a shared library. With hidden visibility, they symbols are marked as “private extern”, allowing you to link with them, but not allowing them to leak from a shared library. Any time that shared libraries are involved, you will want hidden visibility and mark your public API functions with default visibility.

 



That's true, but in my particular case I use a symbol list to control which symbols are exported from the shared library.  I don't really care what visibility the static libraries I link to use, since I specify exactly which symbols get exported, and I never export symbols from these external static libraries.

This isn't really what my issue is though.

The problem is that I have a static library which depends on symbols from other libraries.  Once I create a shared library with that static library I don't need to cart around the static library's dependencies anymore, because I no longer need to link against the static library.

This comes up, because in order to create universal libraries on Mac with CUDA, I have to compile the whole library once for 32 bit and once for 64 bit.  I then merge the two libraries into a single library and then use the imported library functionality to tell CMake to treat my new merged library like any other kind of target.  Since I can't use target_link_libraries with an imported target, I have to use set_target_properties(IMPORTED_LINK_INTERFACE_LIBRARIES).  There doesn't seem to be a mechanism to deal with the issue of PRIVATE versus PUBLIC interfaces, unless I'm mistaken.

James

--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Robert Maynard
Can you try something like this?

https://github.com/robertmaynard/Sandbox/blob/master/ImportedLibrary/CMakeLists.txt

I don't see the second shared library linking to the imported static library.


On Wed, Oct 16, 2013 at 3:44 PM, James Bigler <[hidden email]> wrote:

> On Wed, Oct 16, 2013 at 1:34 PM, Giordano Khouri <[hidden email]>
> wrote:
>>
>> The static libraries must be compiled with -fvisibility=hidden. Symbols
>> with default visibility are marked as “public” and will leak from a shared
>> library. With hidden visibility, they symbols are marked as “private
>> extern”, allowing you to link with them, but not allowing them to leak from
>> a shared library. Any time that shared libraries are involved, you will want
>> hidden visibility and mark your public API functions with default
>> visibility.
>>
>>
>>
>>
>
> That's true, but in my particular case I use a symbol list to control which
> symbols are exported from the shared library.  I don't really care what
> visibility the static libraries I link to use, since I specify exactly which
> symbols get exported, and I never export symbols from these external static
> libraries.
>
> This isn't really what my issue is though.
>
> The problem is that I have a static library which depends on symbols from
> other libraries.  Once I create a shared library with that static library I
> don't need to cart around the static library's dependencies anymore, because
> I no longer need to link against the static library.
>
> This comes up, because in order to create universal libraries on Mac with
> CUDA, I have to compile the whole library once for 32 bit and once for 64
> bit.  I then merge the two libraries into a single library and then use the
> imported library functionality to tell CMake to treat my new merged library
> like any other kind of target.  Since I can't use target_link_libraries with
> an imported target, I have to use
> set_target_properties(IMPORTED_LINK_INTERFACE_LIBRARIES).  There doesn't
> seem to be a mechanism to deal with the issue of PRIVATE versus PUBLIC
> interfaces, unless I'm mistaken.
>
> James
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake
--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

James Bigler
It doesn't seem to work.

I can't use target_link_libraries on an imported target.

add_library(imported_lib STATIC IMPORTED GLOBAL)
set_target_properties(imported_lib PROPERTIES IMPOARTED_LOCATION "${imported_lib_location}")
target_link_libraries(imported_lib other_lib)

Produces an error:

Attempt to add link library [imported_lib_location] to target imported_lib which is not built in this directory.

James


On Wed, Oct 16, 2013 at 2:12 PM, Robert Maynard <[hidden email]> wrote:
Can you try something like this?

https://github.com/robertmaynard/Sandbox/blob/master/ImportedLibrary/CMakeLists.txt

I don't see the second shared library linking to the imported static library.


On Wed, Oct 16, 2013 at 3:44 PM, James Bigler <[hidden email]> wrote:
> On Wed, Oct 16, 2013 at 1:34 PM, Giordano Khouri <[hidden email]>
> wrote:
>>
>> The static libraries must be compiled with -fvisibility=hidden. Symbols
>> with default visibility are marked as “public” and will leak from a shared
>> library. With hidden visibility, they symbols are marked as “private
>> extern”, allowing you to link with them, but not allowing them to leak from
>> a shared library. Any time that shared libraries are involved, you will want
>> hidden visibility and mark your public API functions with default
>> visibility.
>>
>>
>>
>>
>
> That's true, but in my particular case I use a symbol list to control which
> symbols are exported from the shared library.  I don't really care what
> visibility the static libraries I link to use, since I specify exactly which
> symbols get exported, and I never export symbols from these external static
> libraries.
>
> This isn't really what my issue is though.
>
> The problem is that I have a static library which depends on symbols from
> other libraries.  Once I create a shared library with that static library I
> don't need to cart around the static library's dependencies anymore, because
> I no longer need to link against the static library.
>
> This comes up, because in order to create universal libraries on Mac with
> CUDA, I have to compile the whole library once for 32 bit and once for 64
> bit.  I then merge the two libraries into a single library and then use the
> imported library functionality to tell CMake to treat my new merged library
> like any other kind of target.  Since I can't use target_link_libraries with
> an imported target, I have to use
> set_target_properties(IMPORTED_LINK_INTERFACE_LIBRARIES).  There doesn't
> seem to be a mechanism to deal with the issue of PRIVATE versus PUBLIC
> interfaces, unless I'm mistaken.
>
> James
>
> --
>
> 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://www.cmake.org/mailman/listinfo/cmake


--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Andreas Pakulat-2
Hi James,

On Thu, Oct 17, 2013 at 6:58 PM, James Bigler <[hidden email]> wrote:
It doesn't seem to work.

I can't use target_link_libraries on an imported target.

add_library(imported_lib STATIC IMPORTED GLOBAL)
set_target_properties(imported_lib PROPERTIES IMPOARTED_LOCATION "${imported_lib_location}")

Is this typo in the property name only in the mail or also in your cmake code? It should be IMPORTED_LOCATION of course.
 
target_link_libraries(imported_lib other_lib)

Produces an error:

Attempt to add link library [imported_lib_location] to target imported_lib which is not built in this directory.

Now, without having read all the history, this makes no sense to me. How should cmake link another library into your imported library? This would require re-linking that library, but cmake has no idea whats needed for that since it didn't build that imported library. If you're dealing with static libraries on ELF based systems this might be doable, because you can simply unback the .a archive and re-pack it including new object files or even simply add files to it. However other systems may use different types of static libraries that are not just a simple archive of object files, so this is really specific to a subset of the supported platforms. If you absolutely need that, then I'd write a post-link cmake script for 'other_lib' (assuming that one is built by cmake) that does the necessary steps.

Andreas

--

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://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Transitive linking and static libraries

Matthew Woehlke-2
In reply to this post by James Bigler
On 2013-10-17 12:58, James Bigler wrote:

> It doesn't seem to work.
>
> I can't use target_link_libraries on an imported target.
>
> add_library(imported_lib STATIC IMPORTED GLOBAL)
> set_target_properties(imported_lib PROPERTIES IMPOARTED_LOCATION
> "${imported_lib_location}")
> target_link_libraries(imported_lib other_lib)
>
> Produces an error:
>
> Attempt to add link library [imported_lib_location] to target imported_lib
> which is not built in this directory.

You don't actually want to relink the imported library, just set its
interface libraries:

   set_target_properties(imported_lib PROPERTIES
     IMPORTED_LOCATION "${imported_lib_location}"
     IMPORTED_LINK_INTERFACE_LIBRARIES other_lib)

--
Matthew

--

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://www.cmake.org/mailman/listinfo/cmake