I think it's a coincidence that this worked before, since you're running gcc 4.8 and the libstdc++ headers in the sysroot were also from 4.8.

I think a good long term solution is to switch v8 on gcc to using libc++.  I'll give it a try.

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

commit 553989a96ab5252b545776b14bdd8e5db067d9f0
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Wed Nov 15 23:45:39 2017

Enable libc++ on gcc builds

This is a partial revert of CL [1] which disabled libc++ on gcc builds
because gcc did not have the -nostdlib++ flag.  This CL adds the gcc
logic back, but guarded behind !is_clang.

[1] https://chromium.googlesource.com/chromium/src/+/ff69d3018c42eb994533de337f81d417a0209913

BUG= 785170 
R=dpranke@chromium.org

Change-Id: I9c13a12bcbf296e6e32b29224b50179b2830b7d9
Reviewed-on: https://chromium-review.googlesource.com/772959
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516896}
[modify] https://crrev.com/553989a96ab5252b545776b14bdd8e5db067d9f0/build/config/c++/c++.gni
[modify] https://crrev.com/553989a96ab5252b545776b14bdd8e5db067d9f0/build/config/posix/BUILD.gn

Update: looks like there's still an issue with gcc + debug + libc++ builds, which will be fixed once https://chromium-review.googlesource.com/c/chromium/buildtools/+/773630 lands

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

commit 6cce6ca960b98e252fa2a56f1f8f26ed1d8dae85
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Thu Nov 16 01:38:36 2017

Fix libc++ build when using gcc

BUG= 785170 

Change-Id: I49483805d3b1e419edf7ec2c7910edba87f34da4
[modify] https://crrev.com/6cce6ca960b98e252fa2a56f1f8f26ed1d8dae85/third_party/libc++/BUILD.gn

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

commit fe07dbd3cda6fae7ab89bcefefe3988846626088
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Thu Nov 16 07:31:19 2017

Roll buildtools to 9c40f80

This roll includes 3 revisions:
https://chromium.googlesource.com/chromium/buildtools/+/9c40f80c99981e0e3b8ab444ead3d8de8751c103
https://chromium.googlesource.com/chromium/buildtools/+/6cce6ca960b98e252fa2a56f1f8f26ed1d8dae85
https://chromium.googlesource.com/chromium/buildtools/+/7f134c70f0f86ed35c2ca1f6b834a48c4ba47d3e

BUG= 785170 
TBR=dpranke@chromium.org

Change-Id: Id44d5eb1dfe1cf6e6fe2d505b1929bf38cd3dea5
Reviewed-on: https://chromium-review.googlesource.com/773448
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517014}
[modify] https://crrev.com/fe07dbd3cda6fae7ab89bcefefe3988846626088/DEPS

Thanks. Latest roll worked again:
https://chromium-review.googlesource.com/c/v8/v8/+/774220

Is there anything left to do?

One more problem. This also breaks our Arm debug compiler (none-Android). It broke when the fixed roll landed, which I reverted:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/10827

Bisects locally also to the sysroot update commit.

Looks like v8_linux64_gcc_compile_dbg for the latest roll is also failing:

FAILED: libv8_libbase.so libv8_libbase.so.TOC 
python "../../build/toolchain/gcc_solink_wrapper.py" --readelf="readelf" --nm="nm" --sofile="./libv8_libbase.so" --tocfile="./libv8_libbase.so.TOC" --output="./libv8_libbase.so"  -- g++ -shared -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=gold -B../../third_party/binutils/Linux_x64/Release/bin -Wl,--threads -Wl,--thread-count=4 -Wl,--icf=all -m64 -Werror -Wl,--gdb-index -nodefaultlibs --sysroot=../../build/linux/debian_stretch_amd64-sysroot -L../../build/linux/debian_stretch_amd64-sysroot/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_stretch_amd64-sysroot/lib/x86_64-linux-gnu -L../../build/linux/debian_stretch_amd64-sysroot/usr/lib/x86_64-linux-gnu -Wl,-rpath-link=../../build/linux/debian_stretch_amd64-sysroot/usr/lib/x86_64-linux-gnu -rdynamic -Wl,-O1 -Wl,--gc-sections -o "./libv8_libbase.so" -Wl,-soname="libv8_libbase.so" @"./libv8_libbase.so.rsp"
../../buildtools/third_party/libc++/trunk/include/vector:970: error: undefined reference to 'std::__1::__vector_base_common<true>::__throw_length_error() const'
../../buildtools/third_party/libc++/trunk/include/vector:936: error: undefined reference to 'std::__1::__vector_base_common<true>::__throw_length_error() const'
../../buildtools/third_party/libc++/trunk/include/vector:970: error: undefined reference to 'std::__1::__vector_base_common<true>::__throw_length_error() const'
collect2: error: ld returned 1 exit status

Log from Arm debug compiler (from the build linked by Michael in the last comment):

FAILED: gen/snapshot.cc snapshot_blob.bin 
python ../../tools/run.py ./clang_x86_v8_arm/mksnapshot --turbo_instruction_scheduling --startup_src gen/snapshot.cc --random-seed 314159265 --startup_blob snapshot_blob.bin
./clang_x86_v8_arm/mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./clang_x86_v8_arm/mksnapshot)
./clang_x86_v8_arm/mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./clang_x86_v8_arm/mksnapshot)
./clang_x86_v8_arm/mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /b/build/slave/V8_Arm_-_debug_builder/build/v8/out/Debug/clang_x86_v8_arm/./libv8_libbase.so)
./clang_x86_v8_arm/mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /b/build/slave/V8_Arm_-_debug_builder/build/v8/out/Debug/clang_x86_v8_arm/./libv8_libbase.so)
./clang_x86_v8_arm/mksnapshot: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /b/build/slave/V8_Arm_-_debug_builder/build/v8/out/Debug/clang_x86_v8_arm/./libv8_libplatform.so)
ninja: build stopped: subcommand failed.

So it looks like we need to address these two failures.

Failure #1 should already be addressed by the buildtools roll.  I'll look into the second failure.

That bot manually sets use_custom_libcxx=false.
https://cs.chromium.org/chromium/src/v8/infra/mb/mb_config.pyl?rcl=2db9c912a24e3d20c7847008ace7a97c352dfc1a&l=379

We need to enable libc++ on it to fix the issue.

I see this is why it was disabled on the bot:
https://bugs.chromium.org/p/v8/issues/detail?id=6575
machenbach@ Could anyone with an arm machine debug the crash?

I ran the arm dbg bots with the roll + libc++ and the issue appears to be fixed:
https://chromium-review.googlesource.com/c/v8/v8/+/775320

I'll just change the bot config to remove the "use_custom_libcxx=false" and the roll should be good to go.

Lets go for rolling and reenabling custom libcxx. After all, that's how we ship, right? So we should test with it. I'll disable the failing tests if they still fail.

Lets go for rolling and reenabling custom libcxx. After all, that's how we ship, right? So we should test with it. I'll disable the failing tests if they still fail.

Landed:
https://chromium.googlesource.com/v8/v8/+/b8092f4393b1c66651f14652a79ed87c611080af
I'll wait until I see a green build on the V8 Arm dbg bot before marking as fixed.

> After all, that's how we ship, right?
Yup, for a few months now

Latest build with the roll is green:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug%20builder/builds/10848

Ew, this looks too crashy. Actually all tests crashed. So I better revert:
https://chromium-swarm.appspot.com/task?id=39df3b647e100a10&refresh=10&show_raw=1

reopen

I wonder why the waterfall bot failed, but the trybot succeeded:
https://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_dbg/builds/1913

machenbach@ the configs for the builder and the trybot are slightly different.  Could we make the waterfall builder more similar to the trybot?

builder:
arm_float_abi = "hard"
is_component_build = true
is_debug = true
target_cpu = "arm"
use_goma = true
v8_enable_backtrace = true
v8_enable_slow_dchecks = true
v8_test_isolation_mode = "prepare"

trybot:
is_component_build = true
is_debug = true
target_cpu = "x86"
use_goma = true
v8_enable_backtrace = true
v8_enable_slow_dchecks = true
v8_target_cpu = "arm"
v8_test_isolation_mode = "prepare"

We don't have a trybot for native arm. The trybots are all either Android or simulators. Trybots for native arm were blocked on various things.

Maybe this is a good opportunity to try out the shiny new debug feature on swarming bots?
http://shortn/_gSTdv4iEjN

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

commit 8c7174c87fd6f838e8128cb83a5635671b54abc6
Author: Tom Anderson <thomasanderson@chromium.org>
Date: Fri Nov 17 04:17:41 2017

Always hide libunwind symbols on desktop Linux

CL [1] changed libunwind to export it's symbols in component builds to
fix a fuschia bug.  This is not the right change for desktop Linux,
however, so this CL changes it to export the symbols only on fuschia
component builds.

[1] https://chromium.googlesource.com/chromium/buildtools/+/275b8c481615a168464800fc925364aa1a432d37

BUG= 785170 
TBR=hans@chromium.org

Change-Id: I428c225d632ed5bbf8dc2b43d6d3fd2e1a0d14c2

[modify] https://crrev.com/8c7174c87fd6f838e8128cb83a5635671b54abc6/third_party/libunwind/BUILD.gn

Roll reland stayed green now. Thanks for fixing!