[cfe-dev] Better support for statically linking libc++/libc++abi

[Nico Weber via cfe-dev]

On Thu, Oct 15, 2015 at 2:20 PM, Nico Weber <thakis at chromium.org> wrote:

> Hi,
>
> 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 `__visibility__("default")` and `#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.)
>
> My requests:
> 1. 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?
> 2. 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?
>

I forgot a third one:
3. It'd be cool if there was some supported way to build libc++abi in a way
that makes it not add a dependency on cxa_demangle() from
default_terminate_handler() in cxa_default_handlers.cpp. This one call
keeps cxa_demangle() alive, and that takes several hundreds kB of code. For
apps sensitive to size (e.g. mobile apps), paying this size cost for almost
no benefit seems suboptimal. (We're currently adding an empty
cxa_demangle() to one of our source files so that the linker picks that
over the one in libc++abi, but that's fairly hacky.)

I'm happy to do the typing for each of these three if there's agreement
that either of these would be a useful thing to have.

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151015/35ab47e2/attachment.html>