This patch add the CMake option LIBCXX_ENABLE_STATIC_ABI_LIBRARY which, when enabled, will link libc++ against the static version of the ABI library.
Details
Diff Detail
Event Timeline
cmake/Modules/HandleLibCXXABI.cmake | ||
---|---|---|
85 | Why do you change the name of the library, the name should stay the same, its the extension that changes (and I believe should be implicit based on add_library). | |
lib/CMakeLists.txt | ||
41 | Can you add this in side of a check for the linker type? The options are very GNU centric. | |
test/CMakeLists.txt | ||
47 | Can you explain why this is correct? The tests are meant to test libc++abi. They should link to it either statically or dynamically as built. The libc++ tests however, should not. |
Address inline comments.
cmake/Modules/HandleLibCXXABI.cmake | ||
---|---|---|
85 | The actual library name ('libc++abi.so' or 'libc++abi.a') doesn't change. These are CMake target names for when libc++abi and libc++ are being built intree together. | |
lib/CMakeLists.txt | ||
41 | Sounds like a good change. I'll look into it. | |
test/CMakeLists.txt | ||
47 | Because when libc++ statically links to libc++abi then all of the symbols from libc++abi should be available via libc++. If we don't do this and always link the tests to libc++abi then it could hide errors where libc++ doesn't properly expose the required symbols. |
lib/CMakeLists.txt | ||
---|---|---|
41 | To comment on this further. The correct thing to do would be to use find_library with the static library name. However there are some consumers of libc++ that depend on libc++'s CMake not requiring that the library be found at configuration time since it will not yet exist. This is also the reason why use use LIBCXX_CXX_ABI_LIBRARY_PATH to supply the library's directory and not the full path of the library file. |
CMakeLists.txt | ||
---|---|---|
64 | Maybe this should be something like LIBCXX_STATIC_LIBCXXABI. Otherwise, we need checks for the case that we are trying to use libsupc++/libcxxrt and don't have a static version available. | |
74 | Any reason to not support this on Darwin really? I think that we can build a DSO for libc++ and just grab the $<TARGET_OBJECTS:c++abi> (or a static archive/library). | |
cmake/Modules/HandleLibCXXABI.cmake | ||
85 | Yeah, thats what happens when you look at a patch set out of order :-p. | |
test/CMakeLists.txt | ||
47 | Agreed, but the libc++abi tests shouldn't try to pull the symbols indirectly from libc++. They should have direct access to libc++abi symbols. |
CMakeLists.txt | ||
---|---|---|
64 | Perhaps. Since the option is OFF by default I don't think we *need* checks. I have no problem with these cases failing to link because the library is missing. If a user enables this option they should know that they have a static version of the library available. | |
74 | Because linking libc++ on Darwin is already a mess and it would need to be cleaned up first. I also don't see the motivation to support this on Darwin because libc++ reexports libc++abi.dynlib. | |
test/CMakeLists.txt | ||
47 | This shouldn't affect the libc++abi tests because they don't use the lit.site.cfg generated by libc++. |
Maybe this should be something like LIBCXX_STATIC_LIBCXXABI. Otherwise, we need checks for the case that we are trying to use libsupc++/libcxxrt and don't have a static version available.