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

[Ken Cunningham via libcxx-dev]

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

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 
facet objects.


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 
ODR-violation territory?


(If this is a CS-101 level question that is just obvious to everyone, I 
will take it over to StackOverflow :> )

Ken

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20210809/25239f30/attachment.html>