Add GN targets for libc++ and libc++abi.

third_party/libc++/BUILD.gn

Index: third_party/libc++/BUILD.gn
diff --git a/third_party/libc++/BUILD.gn b/third_party/libc++/BUILD.gn
new file mode 100644
index 0000000000000000000000000000000000000000..4ffe438ad0a96512d5c6f559f562599a256b0440
--- /dev/null
+++ b/third_party/libc++/BUILD.gn
@@ -0,0 +1,92 @@
+# Copyright 2015 The Chromium Authors. All rights reserved.
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file.
+
+shared_library("libc++") {
+  # libc++abi is linked statically into libc++.so. This allows us to get both
+  # libc++ and libc++abi by passing '-stdlib=libc++'. If libc++abi was a
+  # separate DSO, we'd have to link against it explicitly.
+  deps = [
+    "//buildtools/third_party/libc++abi",
+  ]
+
+  sources = [
+    "trunk/src/algorithm.cpp",
+    "trunk/src/bind.cpp",
+    "trunk/src/chrono.cpp",
+    "trunk/src/condition_variable.cpp",
+    "trunk/src/debug.cpp",
+    "trunk/src/exception.cpp",
+    "trunk/src/future.cpp",
+    "trunk/src/hash.cpp",
+    "trunk/src/ios.cpp",
+    "trunk/src/iostream.cpp",
+    "trunk/src/locale.cpp",
+    "trunk/src/memory.cpp",
+    "trunk/src/mutex.cpp",
+    "trunk/src/new.cpp",
+    "trunk/src/optional.cpp",
+    "trunk/src/random.cpp",
+    "trunk/src/regex.cpp",
+    "trunk/src/shared_mutex.cpp",
+    "trunk/src/stdexcept.cpp",
+    "trunk/src/string.cpp",
+    "trunk/src/strstream.cpp",
+    "trunk/src/system_error.cpp",
+    "trunk/src/thread.cpp",
+    "trunk/src/typeinfo.cpp",
+    "trunk/src/utility.cpp",
+    "trunk/src/valarray.cpp",
+  ]
+  include_dirs = [
+    "trunk/include",
+    "../libc++abi/trunk/include",
+  ]
+  cflags = [
+    "-fstrict-aliasing",

[earthdok, 2015/05/25 15:48:19]

Why are some flags passed explicitly while others are implemented as build
configs?

[Sam McNally, 2015/05/26 00:55:49]

The others were controlled by existing configs. Added a config for the remaining
options to be shared by this and libc++abi.

+    "-nostdinc++",
+    "-std=c++11",
+  ]
+  configs -= [
+    "//build/config/gcc:no_exceptions",

[earthdok, 2015/05/25 15:48:19]

Will those work with clang?

[Sam McNally, 2015/05/26 00:55:49]

Yes.

+    "//build/config/compiler:no_rtti",
+    "//build/config/gcc:symbol_visibility_hidden",
+    "//build/config/compiler:chromium_code",
+  ]
+  configs += [
+    "//build/config/compiler:rtti",
+    "//build/config/compiler:no_chromium_code",
+    "//build/config/sanitizers:sanitizer_options_link_helper",
+  ]
+  ldflags = [ "-nodefaultlibs" ]
+
+  # TODO(GYP): Remove "-pthread" from ldflags. It somehow causes a warning from
+  # clang about an unused compilation option.
+  # TODO(earthdok): find out what's causing the warning.
+  libs = [
+    "c",
+    "gcc_s",
+    "pthread",
+    "rt",
+  ]
+}
+
+group("libcxx_proxy") {
+  deps = [
+    ":libc++",
+  ]
+  public_configs = [ ":link_helper" ]
+}
+
+config("link_helper") {
+  ldflags = [
+    "-stdlib=libc++",
+
+    # Normally the generator takes care of RPATH. Our case is special because
+    # the generator is unaware of the libc++.so dependency. Note that setting
+    # RPATH here is a potential security issue.
+    # See: https://code.google.com/p/gyp/issues/detail?id=315
+    "-Wl,-R,\$ORIGIN/",

[Alexander Potapenko, 2015/05/25 08:30:09]

Does the above comment apply to GN?

[earthdok, 2015/05/25 15:48:19]

The security issue here is that a setuid executable (chrome-sandbox) gets a
relative RPATH. In issue 315, this happens due to a bug in GYP. Here, however,
the same problem is caused by our own LDFLAGS, regardless of the build system.

The comment should probably be reworded to emphasize that issue 315 is not the
cause, but another example of the same issue. Also we may want to disable libc++
for chrome-sandbox somehow.

[Sam McNally, 2015/05/26 00:55:49]

Done.

+  ]
+  lib_dirs = [ root_build_dir ]
+}