https://bugs.chromium.org/p/chromium/issues/detail?id=747638 looks eminently relevant.

- not sure what .stamp and -MD have to do with each other, but we could use the SDK's hash as part of the include path like on Windows, or ask jamesr to put a .stamp file back. Evan used -MMD long ago in gyp days, probably because system headers usually don't change and it keeps deps size down.

- yes, just need to update the number here https://chromium.googlesource.com/chromium/src/+/1c688af81fcfa4c072dcca79e698641839e8a42f/build/config/c++/BUILD.gn#57

- we already use chromium's libc++ as of the bug you found, and on linux/arm we use our own libunwind. if we always want to use that libunwind, just changing https://chromium.googlesource.com/chromium/src/+/1c688af81fcfa4c072dcca79e698641839e8a42f/build/config/c++/BUILD.gn#23 to say `|| is_fuchsia` might be enough.

Thanks (sorry, #c0 sounds like I was incoherently drunk, but I wasn't, honest. Just generally incoherent.)

Yeah, the .stamp was a sha1 of the sysroot, so making that a define mostly made it like a version number. The related assumption is that if there was an ABI change (making a lib incompatible), there would also be a header change, so Fuchsia (internally) uses -MD to handle that. It does seem a bit odd to exclude system headers from deps unless we know it's some useful % faster, but I didn't check timings to feel strongly about that one way or the other.

libunwind didn't build when I tried that on Friday, but I haven't dug into why yet. Maybe it just needs to be rolled, or likely at least needs a Fuchsia-specific config.h.

Re: sysroot changes.

I looked at other things that use sysroot.gni for comparison. I didn't test (just looked at gn files), but I think Android, Mac, and iOS all handle this in slightly different ways (Android adds a version to some java thing, Mac has the sdk path similar to Windows, and iOS adds a version to the config (and maybe the sdk path similar to Mac?).

I don't see the Linux && use_sysroot path doing anything to handle this though.

(Aside, did we just change this on Windows by switching to clang or does clang-cl /showIncludes do the same as cl?)

Anyhoo, ignoring Linux, I think I'll just go with the Mac/Windows way since it's simplest (and we already have a .hash file sitting there from update_sdk.py).

https://chromium-review.googlesource.com/c/594270 and https://chromium-review.googlesource.com/c/594271.

Building libunwind seems fine now, I didn't go back to figure out what made this work. (It was this before for reference https://www.irccloud.com/pastebin/E1gDHH2r/)

> (Aside, did we just change this on Windows by switching to clang or does clang-cl /showIncludes do the same as cl?)

(clang-cl /showIncludes should do the same as cl, which iirc is "include system include paths" I believe. Yup: http://llvm-cs.pcc.me.uk/tools/clang/lib/Frontend/CompilerInstance.cpp#464)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/335548b45d17d78abbad540672d8db89dcbb1491

commit 335548b45d17d78abbad540672d8db89dcbb1491
Author: Scott Graham <scottmg@chromium.org>
Date: Mon Jul 31 16:28:29 2017

fuchsia: Build libunwind on Fuchsia too

For https://chromium-review.googlesource.com/c/594270.

Bug: 707030,  750392 
Change-Id: I438a24df6c527c6383c16095645e79284c21a9ca

[modify] https://crrev.com/335548b45d17d78abbad540672d8db89dcbb1491/third_party/libc++abi/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/838f297722836d123b45db07a9d2c09f49a160de

commit 838f297722836d123b45db07a9d2c09f49a160de
Author: Scott Graham <scottmg@chromium.org>
Date: Mon Jul 31 19:41:38 2017

Revert "Roll gn c5323f29dd..b1573039b7 (r482038:r486916)"

This reverts 
commit 27f253f9a92f1f7d2ea72c05419b50506b016221
commit afba46cd46efe9456eeb61b1902f35189d374419

Breaks Android when rolled into Chromium, e.g.: https://luci-milo.appspot.com/buildbot/tryserver.chromium.android/android_clang_dbg_recipe/320667
as attempted here.

Bug: 707030,  750392 ,  750810 
Change-Id: I87aa201340e6b6d57b0083d3a279ca8da4b7d75e

[modify] https://crrev.com/838f297722836d123b45db07a9d2c09f49a160de/linux64/gn.sha1
[modify] https://crrev.com/838f297722836d123b45db07a9d2c09f49a160de/mac/gn.sha1
[modify] https://crrev.com/838f297722836d123b45db07a9d2c09f49a160de/win/gn.exe.sha1

I think things went a bit askew here - we aren't ready to support statically linked libc++ in Fuchsia at this stage, so we'd really strongly prefer Chromium dynamically link to our standard lib.  I'll add the libc++ headers and link .so's back to the SDK.  This is important to us so we can use c++ in client libraries (which is not necessarily where we want to be long-term, but it's where we are today) and will be needed when we ship out sanitizer support as we'll be shipping different variants of the standard library to support different sanitizer combinations.

Your client libraries can link against your .so. We don't pass any C++ objects to client libraries, so us linking statically against our thing shouldn't be a problem.

re asan, we'll burn that bridge when we get there :-)

OK - that works for now.  One thing to be careful about is leaking C++ exceptions through calls, which is somethings both sides of any client library have to be careful about, but it seems unlikely to bite us in practice.

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

commit 131568b82901daf84658a300210a9002949b54a2
Author: Scott Graham <scottmg@chromium.org>
Date: Tue Aug 01 17:20:44 2017

fuchsia: Roll SDK to 2bebd264dfe3bec89469a4179a8292b416cdf2fa

Not the normal simple update-the-hash SDK update. Changes:

- Use our own libunwind (as it's been removed from the Fuchsia SDK);

- Use the toolchain hash as a version #define instead of the .stamp in
  sysroot (which has been removed). The Fuchsia team builds with -MD to
  cause rebuilds after ABI changes, Chromium builds with -MMD. The
  global define ensures we rebuild on SDK updates;

- Update clang version to '6.0.0' to get correct builtins lib;

- Update docs for pulling SDK from prebuilt package, rather than doing
  local builds.

- Don't include libc++ and libunwind .so into the runner disk image, as
  we link to them statically now.

Bug: 707030,  750392 
Change-Id: I6702ce208e23288107db00d80f4bed7f875820ae
Reviewed-on: https://chromium-review.googlesource.com/594270
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491035}
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/DEPS
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/build/config/c++/BUILD.gn
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/build/config/fuchsia/BUILD.gn
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/build/config/sysroot.gni
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/build/fuchsia/test_runner.py
[modify] https://crrev.com/131568b82901daf84658a300210a9002949b54a2/docs/fuchsia_sdk_updates.md

This mostly rolled; release works now.

In component debug builds though, base fails to link against _Unwind* https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.fyi%2FFuchsia__dbg_%2F5078%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout .

Previously we linked base against libunwind.so, but I believe now _Unwind* are in Chromium's libc++.so, which doesn't export those symbols after https://codereview.chromium.org/2953323002. Thomas said this was necessary to avoid conflicts with glibc symbols.

With that in mind, does https://chromium-review.googlesource.com/c/596667 seem plausible? (I wonder if there's a magic way to tryjob that against Chromium now with gerrit before landing in buildtools?)

> (I wonder if there's a magic way to tryjob that against Chromium now with gerrit before landing in buildtools?)

Ooh, I think this will work: https://chromium-review.googlesource.com/c/596668 (A thing that gerrit makes better!)

> > (I wonder if there's a magic way to tryjob that against Chromium now with gerrit before landing in buildtools?)

> Ooh, I think this will work: https://chromium-review.googlesource.com/c/596668 (A thing that gerrit makes better!)

Or not. Drat. I think the bots don't pull all branch heads so you can't refer to an uncommitted subrepo commit in src DEPS still.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/buildtools/+/275b8c481615a168464800fc925364aa1a432d37

commit 275b8c481615a168464800fc925364aa1a432d37
Author: Scott Graham <scottmg@chromium.org>
Date: Tue Aug 01 18:45:27 2017

Only disable export of libunwind symbols when libcpp is static

src tryjob at https://chromium-review.googlesource.com/c/596668.

Bug:  750392 ,  593874 
Change-Id: I3becf1ff62db61a2f0c630516bad5fffefac7d2d

[modify] https://crrev.com/275b8c481615a168464800fc925364aa1a432d37/third_party/libunwind/BUILD.gn

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

commit baca0c48578ca9509e5aa4bf94a1083f80106ca3
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Aug 02 01:42:21 2017

fuchsia: roll buildtools to c950cb0

c950cb0 Only disable export of libunwind symbols when libcpp is static

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_arm

Bug:  750392 ,  593874 
Change-Id: I420202d5c83663da56654009350206784c7f6bc5
Reviewed-on: https://chromium-review.googlesource.com/596668
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491182}
[modify] https://crrev.com/baca0c48578ca9509e5aa4bf94a1083f80106ca3/DEPS

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

commit 05c7a3f218d4ff99a09fade8014ad2d529565581
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Aug 02 01:57:55 2017

fuchsia: Make test binaries depend on exe_and_shlib_deps

This resolves e.g. base_unittests not being able to find operator new,
string::string(), etc. in Debug (is_component_build=true) builds.

This matches other platforms, but was missed in creating the Fuchsia
test() template.

Bug:  750392 
Change-Id: I1a7ba2988e9d991f26d392eeab670f3a100de319
Reviewed-on: https://chromium-review.googlesource.com/596520
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491208}
[modify] https://crrev.com/05c7a3f218d4ff99a09fade8014ad2d529565581/testing/test.gni

Until we decide differently about static-ness and/or who's libunwind we're going to use.