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

Nico Weber via libcxx-dev libcxx-dev at lists.llvm.org
Sat Jun 22 03:26:11 PDT 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190622/7ecdba6c/attachment.html>


More information about the libcxx-dev mailing list