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

[Nico Weber via cfe-dev]

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

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

It looks like compnerd is going the more useful "send patch, not email"
route for (1) here: http://reviews.llvm.org/D14789

I'd still appreciate if defining projects defining these macros to nothing
is considered a good idea, or if these are considered "internal" macros.

Eric told me he's fine with something for (3) over IRC, so that part
probably only needs a patch too.

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