Make it possible to change libc++ library files used for android

Make it possible to change libc++ library files used for android

Useful for specifying specific or modified libc++ library files instead of
always using the one in android_ndk_root.

Committed: https://crrev.com/0d15a85e73998a1de32384734f13c4e9b5f07e8f
Cr-Commit-Position: refs/heads/master@{#337797}

[the_jk, 2015-07-06 11:20:17]

the_jk@opera.com changed reviewers:
+ dpranke@google.com, thakis@chromium.org

[Dirk Pranke, 2015-07-06 21:29:32]

dpranke@chromium.org changed reviewers:
+ dpranke@chromium.org

[Dirk Pranke, 2015-07-06 21:29:32]

lgtm

[Nico, 2015-07-06 21:33:01]

lgtm, but can you explain what you intend to use this for?

[the_jk, 2015-07-07 09:12:15]

On 2015/07/06 21:33:01, Nico wrote:
> lgtm, but can you explain what you intend to use this for?

Short version: for temporary workarounds and project specific modifications of
the libc++ library

Longer version: we use it two projects at the moment:
Project 1 wants a smaller libc++_static.a file (more similar in size to stlport)
so they repackage and remove some (to them) useless symbols (exception handling,
unwinding and unused methods from the CXXABI) from the library before linking.
Project 2 works around a bug in the exception handling in libc++ on non-arm
platforms when compiling with clang and not gcc by recompiling libc++ themselves
and linking to the recompiled version

[the_jk, 2015-07-08 09:05:19]

The CQ bit was checked by the_jk@opera.com

[commit-bot: I haz the power, 2015-07-08 09:05:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1215713006/1

[commit-bot: I haz the power, 2015-07-08 10:12:07]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-07-08 10:13:27]

Patchset 1 (id:??) landed as
https://crrev.com/0d15a85e73998a1de32384734f13c4e9b5f07e8f
Cr-Commit-Position: refs/heads/master@{#337797}

[Nico, 2015-07-08 15:23:33]

On 2015/07/07 09:12:15, the_jk wrote:
> On 2015/07/06 21:33:01, Nico wrote:
> > lgtm, but can you explain what you intend to use this for?
> 
> Short version: for temporary workarounds and project specific modifications of
> the libc++ library
> 
> Longer version: we use it two projects at the moment:
> Project 1 wants a smaller libc++_static.a file (more similar in size to
stlport)
> so they repackage and remove some (to them) useless symbols (exception
handling,
> unwinding and unused methods from the CXXABI) from the library before linking.

You can get at least some of that without hacking up libc++.
https://codereview.chromium.org/1215673002/ is how we exclude the demangler in
chromium.

> Project 2 works around a bug in the exception handling in libc++ on non-arm
> platforms when compiling with clang and not gcc by recompiling libc++
themselves
> and linking to the recompiled version

Is this bug filed somewhere?

[the_jk, 2015-07-09 14:24:17]

On 2015/07/08 15:23:33, Nico wrote:
> On 2015/07/07 09:12:15, the_jk wrote:
> > On 2015/07/06 21:33:01, Nico wrote:
> > > lgtm, but can you explain what you intend to use this for?
> > 
> > Short version: for temporary workarounds and project specific modifications
of
> > the libc++ library
> > 
> > Longer version: we use it two projects at the moment:
> > Project 1 wants a smaller libc++_static.a file (more similar in size to
> stlport)
> > so they repackage and remove some (to them) useless symbols (exception
> handling,
> > unwinding and unused methods from the CXXABI) from the library before
linking.
> 
> You can get at least some of that without hacking up libc++.
> https://codereview.chromium.org/1215673002/ is how we exclude the demangler in
> chromium.

Thanks for the link, yeah for the demangler that approach works quite nicely, I
had more trouble with the unhandled exception handler(s) and
generally all of the exception code. Especially when dealing with multiple
arch's.

> > Project 2 works around a bug in the exception handling in libc++ on non-arm
> > platforms when compiling with clang and not gcc by recompiling libc++
> themselves
> > and linking to the recompiled version
> 
> Is this bug filed somewhere?

It is now:
https://code.google.com/p/android/issues/detail?id=179410