When using LLVM unwinder and static unwinder option is set, merge
libc++abi.a and libunwind.a into a single archive. libc++ already
supports merging libc++abi.a and libc++.a into a single archive; with
this change, it is possible to also include libunwind.a in the same
archive which is useful when doing static link and using libc++ as
a default C++ library and compiler-rt as a default runtime library.
Details
- Reviewers
EricWF beanz jroelofs - Commits
- rG56a1f071567f: [CMake][libcxxabi] Support merging objects when statically linking unwinder
rCXXA318563: [CMake][libcxxabi] Support merging objects when statically linking unwinder
rL318563: [CMake][libcxxabi] Support merging objects when statically linking unwinder
Diff Detail
- Repository
- rL LLVM
Event Timeline
The only one I can think of is the consistency with libc++: I've blatantly copied the implementation used by libc++, but I'd be perfectly happy to redo this in plain CMake if people are fine with it (and also update libc++ to use the same approach).
Rather than hand rolling ar commands, could we make libunwind, libcxxabi, and libcxx produce object libraries, then we could just create normal static library targets with the object libraries as sources.
Thoughts?
That's a great suggestion! libunwind and libc++abi already produce object libraries so using that approach makes this change even simpler.
One small nitpick, otherwise LGTM!
src/CMakeLists.txt | ||
---|---|---|
157 | You should be able to do this with list(APPEND ...) instead of set. |
I presume that this only works as long as you build libunwind and libcxxabi together in a single build instead of building them standalone? (Or put another way; when building llvm+clang+lld on linux, for linux, intended to be used as cross compiler for windows - is there any way to build libunwind+libcxxabi+libcxx within the same source tree for i686,x86_64,arm,arm64 windows/mingw?)
@mstorsjo that is the problem that the LLVM/runtimes directory solves. It supports building all the runtime libraries as a single build with one build-tree per target and the management of separate build trees is handled by the build system.
You should be able to do this with list(APPEND ...) instead of set.