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