On Wed, Oct 16, 2013 at 1:34 PM, Giordano Khouri <[email protected]>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 via email to