[CMake] 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 <jamesbigler at gmail.com> wrote:
> 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
>
> --
>
> 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