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

Isuru Fernando via libcxx-dev libcxx-dev at lists.llvm.org
Fri Aug 6 06:40:21 PDT 2021

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++.


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>

More information about the libcxx-dev mailing list