nikic added a comment.

In D125683#3815348 <https://reviews.llvm.org/D125683#3815348>, @ldionne wrote:

> In D125683#3811492 <https://reviews.llvm.org/D125683#3811492>, @nikic wrote:
>
>> I have some concerns about this change:
>>
>> - It makes it fundamentally impossible to link against a static 
>> system-libcxxabi (or any other `LIBCXX_CXX_ABI` option). This is currently 
>> already broken (https://github.com/llvm/llvm-project/issues/57759), but used 
>> to work prior to LLVM 15.
>> - It makes it fundamentally impossible to use a linker script for the shared 
>> library while linking the abi library into the static library. I think this 
>> currently doesn't work either, but would be trivial to support. (I was going 
>> to work on this when I found this revision.)
>>
>> I think both of these points highlight that 
>> `LIBCXX_CXX_ABI=libcxxabi-objects` is not the correct representation for 
>> this functionality.
>
> I don't think these limitations are an inherent property of this approach. 
> What I'm trying to do with this change is eliminate these boolean flags that 
> control how we build the library to instead use a more open-ended selection 
> mechanism that is more flexible, more expressive, and which reduces the need 
> for `if(....)` within the build.
>
> I think the fundamental problem we have is that the ABI library for the 
> static libc++ and for the shared libc++ are selected in one go. If we could 
> instead specify the choice of the ABI library for each independently (for 
> example `-DLIBCXX_CXX_SHARED_ABI=libcxxabi 
> -DLIBCXX_CXX_STATIC_ABI=system-libcxxabi`), would that solve your problem? 
> Also, this would actually increase the flexibility of the current build by a 
> significant margin without much complexity on the libc++ CMake side.

This would indeed address the second point, but not the first. For that, one 
would have to add additional variations like `system-libcxxabi-objects`, which 
would end up increasing the possible abi choices by a factor of two (unless 
static linking doesn't make sense for some of them).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125683/new/

https://reviews.llvm.org/D125683

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to