I wonder if we should just use the in-chromium-tree libc++ on Fuchsia (i.e. add `|| is_fuchsia` to https://cs.chromium.org/chromium/src/build/config/c%2B%2B/c%2B%2B.gni?type=cs&q=custom_libcxx&sq=package:chromium&l=11) -- https://docs.google.com/document/d/1zmHUXlpGNXB433wHnr40dLwj7c-USsIVlyAeH7vOI9o/edit#heading=h.bfky2xssferh

Yes, r307856 is the likely culprit. What has changed is that Fuchsia Clang driver is now looking for C++ runtime in <toolchain_dir>/lib/<x86_64|aarch64>-fuchsia e.g. headers should be in <toolchain_dir>/lib/<x86_64|aarch64>-fuchsia/include/c++/v1, we no longer ship these as part of sysroot, instead they're part of the toolchain.

What does "part of the toolchain" mean? In the clang package?

We build an entire toolchain, not just clang. What goes into the toolchain is controlled by https://fuchsia.googlesource.com/third_party/clang/+/master/cmake/caches/Fuchsia-stage2.cmake#52, that includes runtimes which includes C++ runtimes for x86_64-fuchsia and aarch64-fuchsia targets.

Right, but I think we don't use that toolchain in chrome, right?

AFAIK no, so we you plan to continue using your clang, we need to figure how to make it work. Since you also have your own build of libc++, libc++abi and libunwind, you could just use that as you suggested, I think it should just work.

The suggestion from comment 1 (https://chromium-review.googlesource.com/c/582074/9) fails like so: http://build.chromium.org/p/tryserver.chromium.linux/builders/fuchsia/builds/92

FAILED: crypto_unittests 
python "../../build/toolchain/gcc_link_wrapper.py" --output="./crypto_unittests" -- ../../third_party/llvm-build/Release+Asserts/bin/clang++ -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,--no-as-needed -lpthread -Wl,--as-needed -fuse-ld=lld --target=x86_64-fuchsia -resource-dir ../../third_party/fuchsia-sdk/toolchain_libs/clang/6.0.0 -Wl,-z,stack-size=0x800000 -nodefaultlibs -m64 -Werror -Wl,-O1 -Wl,--gc-sections --sysroot=../../third_party/fuchsia-sdk/sysroot/x86_64-fuchsia -o "./crypto_unittests" -Wl,--start-group @"./crypto_unittests.rsp"  -Wl,--end-group   -lmxio -lmagenta -lunwind -lc -lm -llaunchpad 
/b/c/b/linux/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: __udivti3
>>> referenced by div.c:173 (../../third_party/boringssl/src/crypto/fipsmodule/bn/div.c:173)
>>>               bcm.o:(BN_div) in archive obj/third_party/boringssl/libboringssl.a
/b/c/b/linux/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: undefined symbol: __umodti3
>>> referenced by div.c:645 (../../third_party/boringssl/src/crypto/fipsmodule/bn/div.c:645)
>>>               bcm.o:(BN_is_prime_fasttest_ex) in archive obj/third_party/boringssl/libboringssl.a
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)

That's because we pass -nodefaultlibs in https://cs.chromium.org/chromium/src/build/config/c%2B%2B/BUILD.gn?q=c%5C%2B%5C%2B/build.gn&sq=package:chromium&dr to suppress linking of libc++ from the default location, but that then also disables linking in third_party/fuchsia-sdk/toolchain_libs/clang/6.0.0/lib/fuchsia/libclang_rt.builtins-x86_64.a Since the builtins lib has an arch-specific name, manually adding that to the link line in .gn is pretty annoying too.

So the options are to either manually add that even though it's annoying with the arch, or to -isystem the libc++ headers from the SDK (at third_party/fuchsia-sdk/sysroot//x86_64-fuchsia/include/c++/v1/ -- hmm that looks arch-specific too :-/). I guess I'll try the first option first.

(We should probably give clang a -nodefaultlibs++ flag that only disables the c++ standard library, then we could remove https://cs.chromium.org/chromium/src/build/config/c%2B%2B/BUILD.gn?type=cs&q=nodefaultlib+file:%5C.gn&sq=package:chromium&l=32 too. But that doesn't help with the current roll.)

After quite a bit of back and forth, Fuchsia seems to be building again with patch set 16 of https://chromium-review.googlesource.com/c/582074 . It's pretty hacky, but hey.

Some advance notice and a way to be able to adapt to these changes asynchronously (e.g. so that we could first update compilers, then switch to the new way in a separate commit, and then update compilers again -- meaning there'd have to be a switch to opt in/out for the new behavior) would be very appreciated going forward. Clang rolls require wild flailing way too often, and I would've liked to go to bed a few hours ago. Also, the CL description of r307856 doesn't say _why_ searching for C++ library headers and libraries in directories that are part of the toolchain distribution rather than sysroot is an improvement.

It should be an improvement because Fuchsia developers will no longer have to build C++ libraries themselves which is what they had to do in the past. This turned out to be very painful multi-stage process (build Magenta's sysroot using Make, build C++ libraries using CMake, build Fuchsia using GN). Since C++ libraries are also part of LLVM and they're developed together with the rest of LLVM, I think it's cleaner if they're shipped together, this how official Clang distribution works.

This change should have been transparent for anyone using Fuchsia's Clang toolchain, but unfortunately turned out to be breaking for people using their own Clang build like Chromium, I apologize about that. I agree that we need a better channel for communicating these kind of changes. One thing I can do is CC you on any change that might be potentially affecting Chromium in Phabricator.

Just mailing me isn't sufficient; we have about 5 people doing clang rolls in a lose rotation. Maybe you could email clang@chromium.org. Also, I think most of us at least skim cfe-commits, so if you do a breaking change, it helps if you explicitly point that out in the commit message. But ideally, as said above, when you do a breaking change, provide a flag to opt out of that change and leave that flag around for a month or so. Then we can update our compiler, then migrate to the New Way asynchronously with compiler updates (by adding the opt-out flag when we roll and then removing it later), and then remove that flag again once we've migrated.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c688af81fcfa4c072dcca79e698641839e8a42f

commit 1c688af81fcfa4c072dcca79e698641839e8a42f
Author: Nico Weber <thakis@chromium.org>
Date: Mon Jul 24 11:25:28 2017

Roll clang 307486:308728.

Ran `tools/clang/scripts/upload_revision.py 308728`.

This changes the clang version from 5.0.0 to 6.0.0, so simplify
some things that dealt with both numbers.

This changes clang to no longer look for libc++ headers in the
Fuchsia SDK.  To keep things building, use "our" libc++, like
on linux (use_custom_libcxx).  This in turn means we pass
-nodefaultlibs to the linker, which sadly also disables the
automatic linking of clang_rt.builtins, so do that manually now.
(In exchange, we no longer need to pass in -resource-dir.)

This makes -Wformat fire in Google Toolbox for Mac in iOS builds,
so disable -Wformat in that config for now.

Bug:  746303 , 746505 , 747638 , 747643 , 724204 

Change-Id: I6196a2a173a1b4871f22d0ce92436d0197fd7845
Reviewed-on: https://chromium-review.googlesource.com/582074
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488946}
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/build/config/c++/BUILD.gn
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/build/config/c++/c++.gni
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/build/config/fuchsia/BUILD.gn
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/build/toolchain/toolchain.gni
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/third_party/google_toolbox_for_mac/BUILD.gn
[modify] https://crrev.com/1c688af81fcfa4c072dcca79e698641839e8a42f/tools/clang/scripts/update.py