[libcxx-dev] [llvm-dev] Shipping custom libc++ on MacOS

[Isuru Fernando via libcxx-dev]

Thanks Louis for the clarification. I'll try to make sure we are using only
one version.

Ken, it's incompatible, but this is an implementation detail and will not
be a problem if you are using only one libc++.
Problems happen when mixing two different versions of libc++.

Isuru

On Fri, Aug 6, 2021 at 7:04 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

>
>
> On Thu, Jul 22, 2021 at 2:08 PM Louis Dionne via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>>
>>
>> On Jul 10, 2021, at 09:33, Isuru Fernando via libcxx-dev <
>> libcxx-dev at lists.llvm.org> wrote:
>>
>> Hi Ken,
>>
>> I'm in the same situation as you in conda package manager.
>> Note that with libcxx 12, https://reviews.llvm.org/D91517 was merged
>> where
>> codecvt with char8_t is added in the middle of a structure instead of at
>> the end.
>> This means that you have to be careful that all applications link to the
>> custom libc++.
>>
>> For libcxx developers,
>> While we are discussing how to avoid ODR violations, is it possible to
>> move the two lines at
>> https://github.com/llvm/llvm-project/blob/llvmorg-12.0.1/libcxx/src/locale.cpp#L210-L211
>>
>> to the bottom to avoid segfaults resulting from this?
>>
>>
>> Generally speaking, we make the assumption that there's a single copy of
>> libc++ in use inside a final linked image. Or if you want to use libc++ as
>> an implementation detail and link it statically, ensure it doesn't export
>> any symbols and has absolutely no ABI surface outside of the executable
>> where it's being used. Chrome does that.
>>
>> Anything else is very brittle, and I'm reluctant to add workarounds that
>> make it look like it works, because you may run into other issues that we
>> won't be able to patch so easily.
>>
>> Louis
>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
>
> I had thought libc++ was more immune to this kind of problem given Apple's
> usual support to deploy on older systems.
>
> If the libc++ structures have changed and are now incompatible with
> previous versions of libc++, would that now mean that an Apple build system
> using the new libc++ structures can no longer target a deployment target
> with an older libc++ (any system prior to the change)?
>
> Ken
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20210806/404b6916/attachment.html>