Chrome for Android switched to libc++ in version 45, which launched a few weeks ago. This went well, thanks for everyone working on libc++ for the great work (If anyone is curious about the issues we had during the transition I’m happy to expand on that, but most of it was fairly boring – tests relying on the iteration order of hash_set etc.)
One feature request of sorts: Chrome for Android statically links libc++ (except for ASan builds, we link dynamically in that case). One side effect of the switch is that the chrome binary grew quite a few public symbols from the libc++ headers. Chrome is built with -fvisibility=hidden, but a bunch of places in libc++ contain explicit visiblity(“default”) annotations. These make a lot of sense for shared-library builds of libc++, but for static library builds it makes less sense.
It looks like it might be possible to work around this by defining _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS, _LIBCPP_EXCEPTION_ABI to nothing, but that seems a bit hacky. (I also don’t know if the prebuilt libc++.a in the Android NDK was built like that, but that’s probably off-topic for this list Also, those symbols can be suppressed via -Wl,–exclude-libs=libc++_static.a anyhow).
In the same vein: Symbols in libc++abi have the same issue, but there’s not even a workaround for it there as far as I can tell – there are a bunch of literal
#pragma GCC visibility push(default)s scattered around. (We don’t currently use libc++abi in chrome/android – we use libgcc and libatomic for now, and we still build with gcc.)
- Would it be possible to put the visibility annotations in libcxxabi behind some macro, so that projects can choose to get private visibility for everything?
- Is defining the three macros I mentioned above a good way to force symbols to not have public visibility in libc++, or should projects not rely on that? In the latter case, could there be an explicit, supported toggle for this too?