Oh, ok, my mistake then. Confusion was caused by the fact that “barstatic” features via “fooshared” were actually used by the outside build tree via yet another exported library “abcshared”. Since “abcshared” is in the same build tree with the other parts, it gets access to “barstatic” regardless if it is exported or not. But it needed “barstatic” to be linked to “fooshared” PUBLIC and not PRIVATE.
I ended up linking “barstatic” in PRIVATE mode to both “fooshared” and “abcshared” and this works fine. To avoid this kind of duplication, there could be some use for mode like PUBLIC_WITHIN_BUILDTREE a bit similar to defining include dirs for build and install separately using a generator expression. Sorry for the hassle and thanks ☺ -Lassi From: Marc CHEVRIER <marc.chevr...@gmail.com> Sent: torstai 28. helmikuuta 2019 12.20 To: cmake-developers@cmake.org; Lassi Niemistö <lassi.niemi...@wapice.com> Subject: RE: [cmake-developers] Mandatory export of a static library dependency 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<mailto: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<mailto:marc.chevr...@gmail.com>> Sent: torstai 28. helmikuuta 2019 11.37 To: cmake-developers@cmake.org<mailto:cmake-developers@cmake.org>; Lassi Niemistö <lassi.niemi...@wapice.com<mailto: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<mailto: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<http://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
