[libcxx-dev] [llvm-dev] Shipping custom libc++ on MacOS
Ken Cunningham via libcxx-dev
libcxx-dev at lists.llvm.org
Mon Aug 9 08:55:32 PDT 2021
On 2021-08-09 7:39 a.m., Louis Dionne wrote:
>> On Aug 6, 2021, at 09:34, Ken Cunningham
>> <ken.cunningham.webuse at gmail.com
>> <mailto: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 <mailto: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 <mailto:libcxx-dev at lists.llvm.org>>
>>> Hi Ken,
>>> I'm in the same situation as you in conda package manager.
>>> Note that with libcxx 12, https://reviews.llvm.org/D91517
>>> <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
>>> 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.
>> I had thought libc++ was more immune to this kind of problem given
>> Apple's usual support to deploy on older systems.
> It can't really be immune to those problems since they are byproducts
> of how linking works at a pretty fundamental level. Back-deploying to
> older platforms works nicely as long as you use the libc++ shipped
> with the system (we make sure of that), or that you "embed" libc++
> into your application by linking it as a static archive and disregard
> the system libc++ altogether (Chrome does that). When you do something
> in-between, that's when things start failing.
>> 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)?
> There was no ABI breaking change to the libc++ structures in
> https://reviews.llvm.org/D91517 <https://reviews.llvm.org/D91517>. We
> still support the same back-deployment targets as before.
Thanks for taking a moment to respond. I always appreciate the feedback
and knowledge I receive here from you and others, and TBH I am usually
reluctant to ask many questions, recognizing the rarefied air around
this place. Despite that, I will humbly ask:
Isuru notes that the facet structure in libc++ used to be ABCD, and now
as of D91517 it is ABCFD, with a new set of fields in the middle. He
notes crashes when mixing binaries built against before and after D91517
versions of libc++, which is fair enough and easy to understand.
However, If you build against libc++ headers with the ABCFD version of
that facet structure, and link either statically or dynamically (it
would seem to not matter which) to a libc++ that was built with an ABCFD
facet structure, then your application will be passing around ABCFD
If you then deploy onto a system with the older ABCD facet structure in
libc++, and you try to pass that ABCFD facet object to any system
framework or library to do something with, will you not be in
(If this is a CS-101 level question that is just obvious to everyone, I
will take it over to StackOverflow :> )
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev