Re: [CMake] Controlling the targets in an export set
On 07/24/2014 01:57 AM, Adar Dembo wrote: I have a project that generates a shared library foo. As part of the build, the bar1, bar2, and bar3 static archives are created, and eventually, foo is linked against all of them. Thus, the project's sole deliverable is libfoo.so; all the necessary symbols from the bar1..bar3 archives are found within libfoo.so. If I try to export foo using install(TARGETS foo EXPORT foo ...) and install(EXPORT foo ...), cmake complains that target foo requires targets bar1, bar2, and bar3, which are not in the export set. I have to add install(TARGETS bar1 EXPORT foo ...) for bar1..bar3 if I want this to succeed. However, this also means that I'm exporting my static archives, which as I wrote earlier aren't necessary. How can I exercise finer-grained control over foo's export set? How can I build an export set containing foo but excluding bar1, bar2, and bar3? You can link your static libraries to your shared library privately hence removing them from foo's interface: target_link_libraries(foo PRIVATE bar1 bar2 bar3) You are probably already aware but just in case ... To portably link archives to shared libraries you need position independent code[1]. Of the objects contained in your archives only those will get included which are required to resolve some reference when creating libfoo.so. Symbols that were contained in objects which were not required in the link will hence not be available. This might seemed to have worked within the project until now given that the archives were in your link interface. Nils [1] http://cmake.org/cmake/help/v3.0/prop_tgt/POSITION_INDEPENDENT_CODE.html -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Controlling the targets in an export set
Thanks, that did the trick (though I had to use LINK_PRIVATE instead of PRIVATE; maybe I'm using an older version of cmake). And yes, I need -fPIC code through and through. I've already taken care of that. And double yes, a few other targets needed to explicitly list foo's transitive dependencies in their own target_link_libraries(). Wasn't too hard to fix though. On Thu, Jul 24, 2014 at 12:15 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 07/24/2014 01:57 AM, Adar Dembo wrote: I have a project that generates a shared library foo. As part of the build, the bar1, bar2, and bar3 static archives are created, and eventually, foo is linked against all of them. Thus, the project's sole deliverable is libfoo.so; all the necessary symbols from the bar1..bar3 archives are found within libfoo.so. If I try to export foo using install(TARGETS foo EXPORT foo ...) and install(EXPORT foo ...), cmake complains that target foo requires targets bar1, bar2, and bar3, which are not in the export set. I have to add install(TARGETS bar1 EXPORT foo ...) for bar1..bar3 if I want this to succeed. However, this also means that I'm exporting my static archives, which as I wrote earlier aren't necessary. How can I exercise finer-grained control over foo's export set? How can I build an export set containing foo but excluding bar1, bar2, and bar3? You can link your static libraries to your shared library privately hence removing them from foo's interface: target_link_libraries(foo PRIVATE bar1 bar2 bar3) You are probably already aware but just in case ... To portably link archives to shared libraries you need position independent code[1]. Of the objects contained in your archives only those will get included which are required to resolve some reference when creating libfoo.so. Symbols that were contained in objects which were not required in the link will hence not be available. This might seemed to have worked within the project until now given that the archives were in your link interface. Nils [1] http://cmake.org/cmake/help/v3.0/prop_tgt/POSITION_ INDEPENDENT_CODE.html -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Controlling the targets in an export set
I have a project that generates a shared library foo. As part of the build, the bar1, bar2, and bar3 static archives are created, and eventually, foo is linked against all of them. Thus, the project's sole deliverable is libfoo.so; all the necessary symbols from the bar1..bar3 archives are found within libfoo.so. If I try to export foo using install(TARGETS foo EXPORT foo ...) and install(EXPORT foo ...), cmake complains that target foo requires targets bar1, bar2, and bar3, which are not in the export set. I have to add install(TARGETS bar1 EXPORT foo ...) for bar1..bar3 if I want this to succeed. However, this also means that I'm exporting my static archives, which as I wrote earlier aren't necessary. How can I exercise finer-grained control over foo's export set? How can I build an export set containing foo but excluding bar1, bar2, and bar3? -- 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://public.kitware.com/mailman/listinfo/cmake
