Allow selection between libstdc++ and libc++ when targeting iOS

Allow selection between libstdc++ and libc++ when targeting iOS

The recommended C++ library on iOS is libc++ but the compiler still default
to libstdc++ so add a new gyp variable "use_system_libcxx" to choose which
C++ library to use.

When building Chrome for iOS, so tool are still build on the host which
targets Mac OS X SDK 10.6 which does not supports libc++ so only enabled the
usage of libc++ when not building for the host.

The version of clang shipped on Google storage does not supports using the
system libc++ so instead use the version of clang shipped with Xcode when
using libc++.

BUG=366744
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=287321

[sdefresne, 2014-07-30 17:32:35]

Please have a look.

[sdefresne, 2014-08-01 17:16:48]

+thakis: FYI

[Nico, 2014-08-01 17:39:20]

Do you really want to add a flag for this? You always want to do this on iOS and
never elsewhere (at the moment), so you could just check OS=="ios" I think.

Anyhoo, if Stuart is happy, this is fine with me too, but:

> When building Chrome for iOS, so tool are still build on the host which
> targets Mac OS X SDK 10.6 which does not supports libc++ so only enabled the
> usage of libc++ when not building for the host.

For iOS builds, you can probably use a newer sdk for host tools?

> The version of clang shipped on Google storage does not supports using the
> system libc++ so instead use the version of clang shipped with Xcode when
> using libc++.

That's easy to change, the bundle script just needs to bundle libc++ headers.
(File a bug on me, and I can do this.)

--

Medium-term, I think iOS builds should end up in a state where they use libc++
for host and target, and where that works with both xcode clang and bundled
clang. I think it's relatively easy to get there.

[stuartmorgan, 2014-08-01 20:12:31]

On 2014/08/01 17:39:20, Nico (away) wrote:
> For iOS builds, you can probably use a newer sdk for host tools?
> [...]
> Medium-term, I think iOS builds should end up in a state where they use libc++
> for host and target, and where that works with both xcode clang and bundled
> clang. I think it's relatively easy to get there.

As a general rule, we try to avoid deviating from what Mac builds do when we
build host tools. The issue is that since we still have host tools that are
built downstream-only, we can end up with bustage that flares up during a merge,
and having to solve compile problems upstream in the middle of a merge is a
colossal pain.

In the long term we should be able to build most/all host tools upstream and the
problem would go away, but until then I'd rather we avoid differences that
aren't absolutely necessary.

[stuartmorgan, 2014-08-01 20:15:09]

LGTM for testing. I'd like the clang version issue resolved before we flip it on
unconditionally and remove the flag.

[sdefresne, 2014-08-02 07:13:19]

On 2014/08/01 17:39:20, Nico (away) wrote:
> Do you really want to add a flag for this? You always want to do this on iOS
and
> never elsewhere (at the moment), so you could just check OS=="ios" I think.
> 
> Anyhoo, if Stuart is happy, this is fine with me too, but:

I want to have a dead switch flag to allow disabling it easily if we notice any
issues related to using libc++. I don't expect any, but let's say it is my
background as an SRE that is talking here.

> > When building Chrome for iOS, so tool are still build on the host which
> > targets Mac OS X SDK 10.6 which does not supports libc++ so only enabled the
> > usage of libc++ when not building for the host.
> 
> For iOS builds, you can probably use a newer sdk for host tools?

I tried and I discovered that Chrome does not compile if targeting SDK 10.7 or
higher due to deprecated warning turned into errors in some files included
(about enumerations regarding Bluetooth). I did not investigate fixing those
issues as I did not want to be dragged down a tarpit.

Do you want me to open a bug for that? Should I sign it to you?

> > The version of clang shipped on Google storage does not supports using the
> > system libc++ so instead use the version of clang shipped with Xcode when
> > using libc++.
> 
> That's easy to change, the bundle script just needs to bundle libc++ headers.
> (File a bug on me, and I can do this.)

I will.

> --
> 
> Medium-term, I think iOS builds should end up in a state where they use libc++
> for host and target, and where that works with both xcode clang and bundled
> clang. I think it's relatively easy to get there.

[sdefresne, 2014-08-04 09:08:48]

The CQ bit was checked by sdefresne@chromium.org

[commit-bot: I haz the power, 2014-08-04 09:10:06]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sdefresne@chromium.org/425313002/20001

[commit-bot: I haz the power, 2014-08-04 11:28:08]

Change committed as 287321