[CMake] Proper way to export a library

Thu Oct 31 15:38:29 EDT 2013

I am a firm believer that static libraries should have hidden visibility. This is based on my experience on the Mac and may be different in Linux.

A shared library (dylib, framework) can export a symbol that came in from a static library as a private extern. If the symbol is extern (visibility=default) in the static library, the shared library cannot hide it unless the shared library is linked using an explicit list of the symbols to export. A list of exports maybe isn't so bad for a small to intermediate C library, but for any kind of C++ library, it's a huge pain. The proper use of visibility avoids all that pain.

The static library symbol visibility makes no difference when the static library is linked into an executable.

> -----Original Message-----
> From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On
> Behalf Of J Decker
> Sent: Thursday, October 31, 2013 3:27 PM
> To: Hendrik Sattler
> Cc: Matthew Woehlke; cmake at cmake.org
> Subject: Re: [CMake] Proper way to export a library
>
> something like.... (but probably mostly in a common header)
>
> if( IS_THIS_PROJECT )
>   if( UNIX or STATIC )
>       set( EXPORT  )  # nothing, everything is exported by default; gcc/unix
>   else( UNIX or STATIC )
>       set( EXPORT __declspec(dllexport) )
>   endif( UNIX or STATIC )
> else( IS_THIS_PROJECT )
>   # if something else includes this....
>   if( UNIX or STATIC )
>       set( EXPORT extern )
>   else( UNIX or STATIC )
>       set( EXPORT __declspec(dllimport) )
>   endif( UNIX or STATIC )
> endif( IS_THIS_PROJECT )
>
> On Thu, Oct 31, 2013 at 11:46 AM, Hendrik Sattler <post at hendrik-sattler.de>
> wrote:
> >
> >
> > Matthew Woehlke <matthew.woehlke at kitware.com> schrieb:
> >>On 2013-10-31 05:26, Cyrille Faucheux wrote:
> >>> Can you tell me a bit more about "implicit compile flags [...] for
> >>imported
> >>> tagets"?
> >>
> >>See documentation on target_compile_definitions.
> >>
> >>> On the library I'm currently working on, with Visual Studio, I have
> >>to
> >>> declare some compile definition in order to get the proper
> >>> "__declspec(dllimport)" or "__declspec(dllexport)" defined (or not
> >>defined
> >>> when compiling/using a static version of this library).
> >>
> >>This sounds like you're doing it wrong.
> >
> > Not really as you can only cover the export import with this case but not
> static vs. dynamic linking to that library with the same header file.
> > That it's usually solved with a define when linking statically
> >
> >>When building with CMake, the preferred way is to unconditionally
> >>define an ABI export symbol via a header which exists for that purpose
> >>(e.g.
> >>config.h, my_package_exports.h, etc.). The value of the definition
> >>however is conditional on a symbol that is only defined when building
> >>the library, to choose between import and export as appropriate.
> >>
> >>Even better, CMake will define <target>_EXPORTS for you when building
> >>a
> >>
> >>library, so you shouldn't need to manually specify any definitions at
> >>all.
> >>
> >>IOW you libraries headers would somewhere contain:
> >>
> >>#if defined(_WIN32)
> >>#  define MYPROJECT_ABI_EXPORT __declspec(dllexport) #  define
> >>MYPROJECT_ABI_IMPORT __declspec(dllimport) #elif __GNUC__ >= 4 #
> >>define MYPROJECT_ABI_EXPORT __attribute__ ((visibility("default"))) #
> >>define MYPROJECT_ABI_IMPORT __attribute__ ((visibility("default")))
> >>#else #  define MYPROJECT_ABI_EXPORT #  define
> MYPROJECT_ABI_IMPORT
> >>#endif
> >>
> >>...and:
> >>
> >>#ifdef mylibrary_EXPORTS
> >>#  define MYLIBRARY_EXPORT MYPROJECT_ABI_EXPORT #else #  define
> >>MYLIBRARY_EXPORT MYPROJECT_ABI_IMPORT #endif
> >>
> >>
> >>That said...
> >>
> >>> Does "implicit compile flags" means that those compile definition
> >>could be
> >>> automatically declared by the imported target?
> >>
> >>...this was my understanding of how target_compile_definitions(PUBLIC)
> >>is supposed to work. (Note: I haven't actually used this feature myself
> >>
> >>yet.)
> >
> >
> > --
> >
> > 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

Khouri  Giordano
Software Technology Researcher

Nikon Inc.
1300 Walt Whitman Road
Melville NY 11747-3064

Office: 631-547-4335    Fax: 631-547-0361

kgiordano at nikon.net     www.nikonusa.com

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.