On Thu, Oct 31, 2013 at 1:21 PM, Hendrik Sattler <p...@hendrik-sattler.de> wrote: > > > Giordano Khouri <kgiord...@nikon.net> schrieb: >>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. > > This is about Windows, not Linux or Mac. Linking libraries works a bit > different there.
While that's true, I will concur that hidden is a good thing; there have been several times I have accidentally defined a function with the same name as some library included by a library by a library by a library that ended up with a stack overflow or other bad behavior; everyone should know how to target every platform :) Microsoft believed in hidden by default for shared libraries. > >>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-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On >>> Behalf Of J Decker >>> Sent: Thursday, October 31, 2013 3:27 PM >>> To: Hendrik Sattler >>> Cc: Matthew Woehlke; cmake@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 >><p...@hendrik-sattler.de> >>> wrote: >>> > >>> > >>> > Matthew Woehlke <matthew.woeh...@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 >> >>kgiord...@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. > > > -- > > 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