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

[Nico Weber via libcxx-dev]

Since we don't use the libc++ cmake build files and override the abi
namespace (*), I think this wouldn't affect us.

*: We currently don't override the abi namespace on Windows, because
there's no competing libc++ there. What's more, the natvis debugger
integration file we use (
https://cs.chromium.org/chromium/src/build/config/c%2B%2B/libc%2B%2B.natvis?q=file:%5C.natvis&sq=package:chromium&dr)
needs to mention the abi namespace name, so I suppose we'd have to
explicitly set the abi namespace to __1 on Windows. Or we could change the
natvis file to say __9000. There's a thread somewhere about upstreaming
that file; we probably would want to have one natvis file per abi version
(with "latest" being a version) anyway.

On Sun, Jun 23, 2019 at 6:31 AM Eric Fiselier via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> 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
>>
> _______________________________________________
> 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/d22f9baa/attachment.html>