[libcxx-dev] should the unstable ABI support building a shared library?

[Richard Smith via libcxx-dev]

Maybe a better approach would be to ensure that the unstable-ABI libc++ has
a different file name / soname version than the stable ABI library. Would
that satisfy the needs of Chromium and Fuchsia?

On Sat, 22 Jun 2019 at 16:55, Petr Hosek <phosek at chromium.org> wrote:

> We cross-compile libc++ for Fuchsia as a shared library with
> LIBCXX_ABI_UNSTABLE in the CMake build so I'd prefer if this was
> overridable/optional.
>
> On Sat, Jun 22, 2019 at 3:26 AM Nico Weber via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> We depend on being able to build libc++ as a shared library
>> with LIBCXX_ABI_UNSTABLE set in Chromium. We build libc++ from source as
>> part of a regular chrome build, and in a component build (where each
>> library of chrome becomes a .so) libc++ must be a .so as well.
>>
>> (We use a custom inline namespace name, and we make sure our libc++ is
>> always on the search path before system libc++).
>>
>> We don't use libc++'s cmake files, so if this is just about libc++'s
>> cmake setup, we don't have an opinion on this.
>>
>> On Sat, Jun 22, 2019 at 12:42 AM Richard Smith via libcxx-dev <
>> libcxx-dev at lists.llvm.org> wrote:
>>
>>> By default, libc++ builds produce a shared library and a static library.
>>> When LIBCXX_ABI_UNSTABLE is enabled, though, that seems like a mistake:
>>> there is no stable interface, so dynamically linking against an
>>> unstable-ABI libc++ shared library will be problematic.
>>>
>>> In addition, if LIBCXX_ABI_VERSION is not specified during
>>> configuration, the default behavior of the build system with
>>> LIBCXX_ABI_UNSTABLE enabled is to produce a libc++.so.1.0 with the unstable
>>> ABI, which causes problems if it's found on the library search path for a
>>> binary built against the normal-ABI libc++.so.1.0. (And in a stock monorepo
>>> build, this means that enabling LIBCXX_ABI_UNSTABLE and then building, say,
>>> llvm and libc++, with a host compiler that uses libc++ as the standard
>>> library, results in broken LLVM binaries in the build area: they were
>>> compiled against the stable libc++ ABI but will pick up an unstable-ABI
>>> version of libc++ at runtime.)
>>>
>>> Perhaps we should refuse to build a shared library version of libc++
>>> with the unstable ABI enabled?
>>> _______________________________________________
>>> libcxx-dev mailing list
>>> libcxx-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190622/25ab8591/attachment.html>