As I said, You don’t have all symbols in fooshared when PUBLIC is used but, because barstatic is PUBLIC, it is included in link commands where fooshared is specified.
For example, specifying command 'target_link_libraries (any PRIVATE fooshared)’ is equivalent to 'target_link_libraries (any PRIVATE fooshared barstatic)’ because barstatic is specified as PUBLIC dependency of fooshared. Le 28 févr. 2019 à 11:14 +0100, Lassi Niemistö <lassi.niemi...@wapice.com>, a écrit : > Hello, > > I understand it is a bit awkward scenario to need to have all symbols from > barstatic available in fooshared and yes I can work around it by the OBJECT > library method. > > However, I see it contradictory to > Get all symbols from barstatic included into fooshared when linking it in > PUBLIC mode > Still need to export also barstatic even when this is not necessary due to 1. > > Clarification: the executable is spit out from the same build/cmake than > fooshared. It uses only barstatic and not fooshared at all. The executable is > not the problem, problem is the exporting of fooshared to external builds. > > This goes towards generic discussion on what is the preferred way of creating > both .so and .a versions of a library, check e.g. > https://stackoverflow.com/questions/2152077/is-it-possible-to-get-cmake-to-build-both-a-static-and-shared-version-of-the-sam. > Although the OBJECT library method works, it is clumsy due to needing to > define target_include_directories, compiler flags etc multiple times and > having yet another named target to maintain. It is more beautiful to just > create the static lib as your base and then link the shared version to it, > although it works only when the shared lib has at least one extra source file > compared to the static version. Or, worked until the export stage. > > -Lassi > > From: Marc CHEVRIER <marc.chevr...@gmail.com> > Sent: torstai 28. helmikuuta 2019 11.37 > To: cmake-developers@cmake.org; Lassi Niemistö <lassi.niemi...@wapice.com> > Subject: Re: [cmake-developers] Mandatory export of a static library > dependency > > Hi, > > It is perfectly normal that CMake requires static library to be exported when > command ’target_link_libraries(fooshared barstatic)’ is specified because > this is equivalent to command 'target_link_libraries(fooshared PUBLIC > barstatic)’. > > As you have already discovered, using command > 'target_link_libraries(fooshared PRIVATE barstatic)’ avoids exporting of > barstatic library. > Now, I think you did a wrong diagnostic regarding your link problems with > this signature. Symbols visibility is not changed by specifying ‘PRIVATE’ but > link commands are changed. With ‘PRIVATE’, the link command for your > executable do not contains anymore a reference to barstatic library. And the > ‘fooshared’ library will contains only objects from ‘barstatic’ needed to > solved unreferenced symbols (so may be not all objects from ‘barstatic’). > > So to solve your problem you have two possibilities: > > > 1. Specify ‘barstatic’ library as dependency of your executable, i.e. > 'target_link_libraries(exec PRIVATE fooshared barstatic)’. > 2. Ensure that all objects of `barstatic` are included in your ‘fooshared’ > library. For that purpose, you can create `barstatic` as OBJECT library and > include all objects in your ‘fooshared’ library using pattern > ‘add_library(fooshared SHARED .. $<TARGET_OBJECTS:barstatic> …)’. But the > most simple is, may be, to put directly all your sources in ‘fooshared’ > library. > > > Le 28 févr. 2019 à 08:25 +0100, Lassi Niemistö <lassi.niemi...@wapice.com>, a > écrit : > > > Hello, > > > > The cmake "users" list did not wake any replies, so posting here as a > > possible bug: > > > > I use CMake 3.13RC1. My project produces, installs and exports a shared > > library target "fooshared". Some logical parts of "fooshared" are reused in > > an executable, so I have placed those sources into an internal static > > library target "barstatic". I have used target_link_libraries(fooshared > > barstatic) to make this work. > > > > Problem: when I try to: > > install(TARGETS fooshared DESTINATION <dest> EXPORT myexport) > > install(EXPORT myexport DESTINATION <dest>) > > ..I get a whine about dependency to "barstatic" which is not in the export > > group "myexport". > > > > I wouldn't like to export "barstatic" at all, it should remain under the > > hood. I tried to use target_link_libraries(fooshared PRIVATE barstatic) > > which cut the export chaining, but then symbols from "barstatic" were not > > available for users of "fooshared" anymore. So I worked around this by > > converting "barstatic" into an object library, but it feels ugly. > > > > Why would CMake require exporting statically linked dependency targets > > among the targets that use them? Feels like a bug to me. > > > > Regards, > > -Lassi Niemistö > > -- > > > > 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-developers
-- 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-developers
