2018-05-20 4:19 GMT+02:00 Ray Donnelly <mingw.andr...@gmail.com>: > On Sat, May 19, 2018 at 11:55 PM, Elvis Stansvik > <elvis.stans...@orexplore.com> wrote: >> 2018-05-19 21:49 GMT+02:00 Mateusz Loskot <mate...@loskot.net>: >>> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stans...@orexplore.com> >>> wrote: >>>> I know this has been asked before, but I've never seen a really >>>> authoritative answer. >>>> >>>> Say I have a simple single-library project. >>>> >>>> The advise I've seen is to not pass SHARED or STATIC to the >>>> add_library(..), but instead let the user pass >>>> -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared >>>> or static. >>>> >>>> That's fine, but leads to packagers having to do ugly things like e.g: >>>> >>>> https://salsa.debian.org/hle/dlib/blob/master/debian/rules >>>> >>>> That is, do two separate configure/build/install, in order to get both >>>> a shared and static version. >>> >>> IMHO, there is nothing ugly in this approach. >>> Not every system allows (or recomments) to generate both, >>> static and shared, from the same object files. >> >> Alright. Yes I'm probably personally leaning towards just using the >> recommended way, with a single add_library(..) and demand >> reconfigure/rebuild/reinstall to get both variants. I was mostly >> curious if you CMake pros on this list had some neat solution I hadn't >> seen before. >> >> Note that I wasn't necessarily suggesting building shared + static >> from the same set of object files (which is indeed not recommended, >> e.g. think of -fPIC), > > Static libraries should be compiled with -fPIC on all systems that > support -fPIC. The reason for this is that you should not make > assumptions about the final target of the static library. There is no > reason it should be excluded from being linked into a shared library > or a ASLR capable executable. On Anaconda Distribution, everything is > compiled with -fPIC on Linux for this reason, and on macOS, -fPIC is > the only option and Windows has always been PIC or at least for as > long as I can remember.
Alright, this was some good bit of info, since I had mostly seen "PIC unnecessarily hurts performance for static libs" kind of advice out there. Thinking about it, in my case, even if PIC did hurt performance a bit, I don't think it's much enough that I should care, for my use case at least. So, with that in mind, is anyone doing this: - Build an object library (with POSITION_INDEPENDENT_CODE) - Build a static library from the object library - Build a shared library from the object library ? Any downsides/gotchas with this approach? The upsides I see are: 1. Sources are compiled once, and the result linked twice. 2. No need for a variable to hold the list of sources. Time savings of 1 may be negligible though, if linking is the lion share of the time (my project is tiny though, so I'm not concerned about build time savings). Elvis > > but just looking for best practices when having >> CMake do the build of both libraries as part of the same build. >> >> Elvis >> >>> Why not view static vs shared as the similar to 32 vs 64 bit? >>> >>> Best regards, >>> -- >>> Mateusz Loskot, http://mateusz.loskot.net >>> -- >>> >>> 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: >>> https://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: >> https://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: https://cmake.org/mailman/listinfo/cmake
