should the unstable ABI support building a shared library?

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 with the unstable ABI, which causes problems if it’s found on the library search path for a binary built against the normal-ABI (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?

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.

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.

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?

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

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 ( 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.