This change is similar to r356150, with the same motivation. The
only difference is that the method used to merge libunwind.a and
libc++abi.a had to be changed to use the same approach as libc++
since we no longer produce object libraries that could be linked
together as we did before. We reuse the libc++ script for merging
archives to avoid duplication between the two projects.
Details
- Reviewers
ldionne EricWF smeenai - Commits
- rCXXA357635: [libc++abi] Do not share an object library to create the static/shared libraries
rG4252555753db: [libc++abi] Do not share an object library to create the static/shared libraries
rL357635: [libc++abi] Do not share an object library to create the static/shared libraries
Diff Detail
- Repository
- rCXXA libc++abi
Event Timeline
I will close https://reviews.llvm.org/D60166 as being superseded by this.
libcxxabi/CMakeLists.txt | ||
---|---|---|
49 | Why are we dropping this? |
libcxxabi/CMakeLists.txt | ||
---|---|---|
49 | AFAICT CMake automatically includes -fPIC for both shared and static library (I checked the generated build.ninja files) so this shouldn't be needed, or do you want to have an explicit option to disable -fPIC? If so, should there be a similar option for libunwind and libc++ as well? |
libcxxabi/CMakeLists.txt | ||
---|---|---|
49 | I don't think it does for static libraries. From https://cmake.org/cmake/help/v3.14/prop_tgt/POSITION_INDEPENDENT_CODE.html:
I'm personally fine with relying on CMAKE_POSITION_INDEPENDENT_CODE to control that, but other folks wanted more control. |
libcxxabi/CMakeLists.txt | ||
---|---|---|
49 | It seems like the -fPIC I saw in build.ninja is added by LLVM, if I do a standalone build of libc++abi, it's not there. |
libcxxabi/src/CMakeLists.txt | ||
---|---|---|
193 | Related to discussion on D60049, should this be set for shared as well or only static? It's unclear to me whether that option should control both or just static? @sbc100 what was your intention? Personally, I'd prefer to introduce: cmake_dependent_option(LIBCXXABI_ENABLE_PIC_SHARED_LIBRARY "LIBCXXABI_ENABLE_SHARED;LIBCXXABI_ENABLE_PIC" ON) cmake_dependent_option(LIBCXXABI_ENABLE_PIC_STATIC_LIBRARY "LIBCXXABI_ENABLE_STATIC;LIBCXXABI_ENABLE_PIC" ON) Then use those dependent options to control PIC independently for shared and static libraries. WDYT? |
libcxxabi/src/CMakeLists.txt | ||
---|---|---|
193 | From a WebAssembly perspective we only needed a way to prevent the static library being built as PIC. Which we now have in the form of the LIBCXXABI_ENABLE_PIC=OFF option. During review somebody pointed out that there are times when one might also want to disable PIC in shared libraries too so we had this option effect both which is probably fine with us too. I'm hoping to fix the issue that is currently present in WebAssembly where PIC code can't linked into static binaries. If I'm not able to do that I'll most likely end up building everything twice creating a complete fork of the lib directory. e.g:
Then the linker would then choose the lib directory to use based weather its building relocatable output or not. If we end up doing that we don't need that much flexibility within a given build because we will be running cmake twice, once for pic and once for non-pic. So basically, no I need that fine grained control for what I'm doing (yet). |
libcxxabi/src/CMakeLists.txt | ||
---|---|---|
193 | I've changed it so that ${LIBCXXABI_ENABLE_PIC} controls both the static and shared case. |
libcxxabi/src/CMakeLists.txt | ||
---|---|---|
192 | You need to do if (LIBCXXABI_ENABLE_PIC) target_set_properties(... ON) endif() Otherwise, you're overwriting the default that's being set through CMAKE_POSITION_INDEPENDENT_CODE. |
Thanks for the refactoring!
libcxxabi/src/CMakeLists.txt | ||
---|---|---|
192 | I'm that user. I use CMAKE_POSITION_INDEPENDENT_CODE=OFF and I don't touch those stinking fine-grained controls. |
Why are we dropping this?