Handle the case when libc++abi and libunwind are being built together
with libc++ in the runtimes build. This logic was used in the previous
implementation but dropped in r374116.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
34–36 | How can it be that ${lib} is equal to cxxabi_static or cxxabi_shared, but it's not a target? The same applies to the unwind_xxx targets. I think this has to do with how you configure your build for Fuchsia with HAVE_LIBCXXABI. Can you show me exactly what arguments are used in the CMake invocation? TBH, I'd like to better understand the purpose of HAVE_LIBCXXABI and HAVE_LIBUNWIND, since those certainly look like slight hacks that would be nice to support better. | |
34–36 | However, feel free to commit this for the time being in order to fix your build. But I'd really like to have the discussion about HAVE_LIBCXXABI, since I've been meaning to have it for a while. |
libcxx/cmake/Modules/DefineLinkerScript.cmake | ||
---|---|---|
34–36 | The issue is that when building these in the runtimes build, they get added in whatever order user specifies on the command-line so by the time we're processing libc++, libc++abi and libunwind may have not yet been processed so if(TARGET "${lib}) is going to fail. D68833 is an alternative solution that's trying to address this issue more generally. |
How can it be that ${lib} is equal to cxxabi_static or cxxabi_shared, but it's not a target? The same applies to the unwind_xxx targets. I think this has to do with how you configure your build for Fuchsia with HAVE_LIBCXXABI. Can you show me exactly what arguments are used in the CMake invocation?
TBH, I'd like to better understand the purpose of HAVE_LIBCXXABI and HAVE_LIBUNWIND, since those certainly look like slight hacks that would be nice to support better.