llvm dev - Feb 2021 - Shipping custom libc++ on MacOS

Hello,

We are working on an application where we want to have full support
for C++17 but still ship on older versions of macOS (10.9/10.10 in
this case). Our plan was to build our own libc++ from llvm and ship it
with the application and then pass "-D_LIBCPP_DISABLE_AVAILABILITY"

This seemed to work fine in internal testing - but then we ran into a
similar issue as the one described here:
https://reviews.llvm.org/D74489#2497044

Now I can patch my copy of libc++ with the upstream fix for this - but
the comment below made me think otherwise:
https://reviews.llvm.org/D74489#2505156

We have run into problem where if you ship your own libc++ the system
frameworks loads the system libc++ and some strange errors happen - we
thought we could work around these issues - but maybe this is just us
being naive.

So I guess my question is - is it possible to ship a custom libc++ in
a .app archive for older versions of macOS in order to use C++17? Or
is my only hope to raise the minimum version of our app and always
link to the system libc++?

Thanks,
Tobias

Hi,

I can't speak for macOS specifically, but in general you can have 
problems on *NIX platforms if you have two libraries that implement the 
same symbols loaded.  Everything in libc++ is in the namespace defined 
by _LIBCPP_ABI_NAMESPACE and then aliased into std.  Can you not define 
this to something custom?  That should give you different symbol names 
and so if you depend on another library that links a different version 
of libc++ (statically or dynamically) you won't conflict.

David

On 01/02/2021 07:37, Tobias Hieta via llvm-dev wrote:
> Hello,
> 
> We are working on an application where we want to have full support
> for C++17 but still ship on older versions of macOS (10.9/10.10 in
> this case). Our plan was to build our own libc++ from llvm and ship it
> with the application and then pass
"-D_LIBCPP_DISABLE_AVAILABILITY"
> 
> This seemed to work fine in internal testing - but then we ran into a
> similar issue as the one described here:
> https://reviews.llvm.org/D74489#2497044
> 
> Now I can patch my copy of libc++ with the upstream fix for this - but
> the comment below made me think otherwise:
> https://reviews.llvm.org/D74489#2505156
> 
> We have run into problem where if you ship your own libc++ the system
> frameworks loads the system libc++ and some strange errors happen - we
> thought we could work around these issues - but maybe this is just us
> being naive.
> 
> So I guess my question is - is it possible to ship a custom libc++ in
> a .app archive for older versions of macOS in order to use C++17? Or
> is my only hope to raise the minimum version of our app and always
> link to the system libc++?
> 
> Thanks,
> Tobias
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> On Feb 1, 2021, at 02:37, Tobias Hieta via libcxx-dev <libcxx-dev at
lists.llvm.org> wrote:
> 
> Hello,
> 
> We are working on an application where we want to have full support
> for C++17 but still ship on older versions of macOS (10.9/10.10 in
> this case). Our plan was to build our own libc++ from llvm and ship it
> with the application and then pass
"-D_LIBCPP_DISABLE_AVAILABILITY"
> 
> This seemed to work fine in internal testing - but then we ran into a
> similar issue as the one described here:
> https://reviews.llvm.org/D74489#2497044
> 
> Now I can patch my copy of libc++ with the upstream fix for this - but
> the comment below made me think otherwise:
> https://reviews.llvm.org/D74489#2505156
> 
> We have run into problem where if you ship your own libc++ the system
> frameworks loads the system libc++ and some strange errors happen - we
> thought we could work around these issues - but maybe this is just us
> being naive.
> 
> So I guess my question is - is it possible to ship a custom libc++ in
> a .app archive for older versions of macOS in order to use C++17? Or
> is my only hope to raise the minimum version of our app and always
> link to the system libc++?
Generally, I would say this is a tricky thing to do. As you mention, the problem
is that if you link against any other library that does link against the
system-provided libc++.dylib, you'll have ODR violations because some
symbols will be found in both libraries. As a result, I believe you could also
end up in a situation where you end up using globals from one library when the
globals from the other library has been initialized. So basically, nothing good
happens.

If you can ensure that your application doesn't pull in the system
libc++.dylib (even transitively), then this would in theory be safe to do. Due
to the brittleness of the solution, my immediate reaction would be to not
recommend that. The reason why some parts of C++17 aren't available on older
platforms is that we put the vtables required for exception classes in the
dylib. That is a code size optimization that we think is worth the trouble. You
can generally use the parts of C++17 APIs that can't throw exceptions even
on older platforms because they don't require those vtable symbols - perhaps
that is something you can consider?

Louis