<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 15, 2015 at 9:16 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 15, 2015 at 2:20 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.)</div><div><br></div><div>My requests:</div><div>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?</div><div>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?</div></div></blockquote></div><br></div></span><div class="gmail_extra">I forgot a third one:</div><div class="gmail_extra">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.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div></blockquote><div><br></div><div>It looks like compnerd is going the more useful "send patch, not email" route for (1) here: <a href="http://reviews.llvm.org/D14789">http://reviews.llvm.org/D14789</a></div><div><br></div><div>I'd still appreciate if defining projects defining these macros to nothing is considered a good idea, or if these are considered "internal" macros.</div><div><br></div><div>Eric told me he's fine with something for (3) over IRC, so that part probably only needs a patch too.</div><div><br></div><div>Nico</div></div></div></div>