Good: https://ci.chromium.org/buildbot/chromium.clang/ToTAndroid/5324
Bad:  https://ci.chromium.org/buildbot/chromium.clang/ToTAndroid/5325

Clang range: 346151:346168

I don't see anything suspicious there. Also, since this is not firing on other Linux bots, it smells like some infra problem.

> Clang range: 346151:346168
>
> I don't see anything suspicious there.

I spoke too soon:


------------------------------------------------------------------------
r346167 | danalbert | 2018-11-05 21:57:46 +0100 (Mon, 05 Nov 2018) | 5 lines

[Driver] Reland again again: Default Android toolchains to libc++.

Landed more fixes to the compiler-rt Android tests.

Original review was https://reviews.llvm.org/D53109.
------------------------------------------------------------------------

We're building the standalone Android toolchain into a sysroot and then using that in the cmake invocation that fails:

Running /b/c/b/ToTAndroid/src/third_party/android_ndk/build/tools/make_standalone_toolchain.py --api=21 --force --install-dir=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64 --stl=libc++ --arch=arm64

Running cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_LIBXML2=FORCE_ON -DLLVM_ENABLE_THREADS=OFF -DCMAKE_C_COMPILER=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/bin/clang -DCMAKE_CXX_COMPILER=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/bin/clang++ -DLLVM_CONFIG_PATH=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/bin/llvm-config '-DCMAKE_C_FLAGS=--target=aarch64-linux-android21 --sysroot=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64/sysroot -B/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64' '-DCMAKE_CXX_FLAGS=--target=aarch64-linux-android21 --sysroot=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64/sysroot -B/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64' '-DCMAKE_ASM_FLAGS=--target=aarch64-linux-android21 --sysroot=/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64/sysroot -B/b/c/b/ToTAndroid/src/third_party/llvm-build/Release+Asserts/android-toolchain-aarch64' -DSANITIZER_CXX_ABI=none -DSANITIZER_CXX_ABI_LIBRARY=c++abi -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-u__cxa_demangle -DANDROID=1 /b/c/b/ToTAndroid/src/third_party/llvm/compiler-rt


So what does "cannot find -lc++" mean? Is it not installed in the sysroot? Is ld not looking there?

I can't see any libc++ in the sysroot

$ ls third_party/llvm-build/Release+Asserts/android-toolchain-aarch64/sysroot/usr/lib | grep c++
libstdc++.a
libstdc++.so

But it has libstdc++? That's surprising given that we pass --stl=libc++ to make_standalone_toolchain.py above...

Sigh, make_standalone_toolchain.py is doing some weird stuff...

def copy_libcxx_libs(src_dir, dst_dir, include_libunwind):
    shutil.copy2(os.path.join(src_dir, 'libc++_shared.so'), dst_dir)
    shutil.copy2(os.path.join(src_dir, 'libc++_static.a'), dst_dir)
    shutil.copy2(os.path.join(src_dir, 'libandroid_support.a'), dst_dir)
    shutil.copy2(os.path.join(src_dir, 'libc++abi.a'), dst_dir)

    if include_libunwind:
        shutil.copy2(os.path.join(src_dir, 'libunwind.a'), dst_dir)

    # libc++ is different from the other STLs. It has a libc++.(a|so) that is a
    # linker script which automatically pulls in the necessary libraries. This
    # way users don't have to do `-lc++abi -lunwind -landroid_support` on their
    # own.
    #
    # As with the other STLs, we still copy this as libstdc++.a so the compiler
    # will pick it up by default.
    #
    # Unlike the other STLs, also copy libc++.so (another linker script) over
    # as libstdc++.so.  Since it's a linker script, the linker will still get
    # the right DT_NEEDED from the SONAME of the actual linked object.
    #
    # TODO(danalbert): We should add linker scripts for the other STLs too
    # since it lets the user avoid the current mess of having to always
    # manually add `-lstlport_shared` (or whichever STL).
    shutil.copy2(os.path.join(src_dir, 'libc++.a'),
                 os.path.join(dst_dir, 'libstdc++.a'))
    shutil.copy2(os.path.join(src_dir, 'libc++.so'),
                 os.path.join(dst_dir, 'libstdc++.so'))

Patch: https://chromium-review.googlesource.com/c/chromium/src/+/1319712

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

commit 6d756ac85b9a9a4e8516c4e3f62ed801f854d168
Author: Hans Wennborg <hans@chromium.org>
Date: Tue Nov 06 19:12:33 2018

Clang update script: fix Android compiler-rt builds after r346167

NDK r16 "helpfully" installs libc++ as libstdc++ to make the NDK's Clang use
that by default. However, we use a more recent Clang, and after r346167 that
starts looking for libc++, which then can't be found due to the renaming.

This hacks around the problem by renaming it back. Well, it makes a copy
actually, to support Clangs both before and after. We should remove all this in
the future when we've moved to a newer NDK.

Bug:  902270 
Change-Id: Ib69be5faeb0e0b0c8b5b2588fdb66610e30de687
Reviewed-on: https://chromium-review.googlesource.com/c/1319712
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Reid Kleckner <rnk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605772}
[modify] https://crrev.com/6d756ac85b9a9a4e8516c4e3f62ed801f854d168/tools/clang/scripts/update.py