[CMake] Transitive linking and static libraries

[James Bigler]

On Wed, Oct 16, 2013 at 1:34 PM, Giordano Khouri <kgiordano at nikon.net>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20131016/cf5a5144/attachment.htm>