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

[Eric Fiselier via libcxx-dev]

I think that's the right approach.

I'll change the namespace for unstable. Since the ABI is unstable I think
the namespace should be as well. So I think I'll make it
`__<version-number>`, so right now it would be __9000. (though that's a bit
long).

I'm less sure what to about the SO version number, but I'm also unfamiliar
with how SO versioning is supposed to work

On Sat., Jun. 22, 2019, 9:44 p.m. Richard Smith via libcxx-dev, <
libcxx-dev at lists.llvm.org> wrote:

> 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
>>>
>> _______________________________________________
> 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/20190623/c5d11774/attachment-0001.html>