Node: v6.5.0 fails to build using clang-3.4.

[Fishrock123]

• Version: v6.5.0
• Platform: Debian, Ubuntu ... using clang-3.4
• Subsystem: build

Our package builds for Debian Wheezy, Ubuntu Precise, and perhaps others, are failing on v6.5.0 using clang-3.4.

This seems to be a regression possibly introduced by V8 5.1.

See also: https://github.com/nodejs/node/pull/8054#issuecomment-243153991

cc @nodejs/v8 @nodejs/ctc

[bnoordhuis]

Can you post or link to the build log?

[chrislea]

What I've seen building 6.5.0 this morning is that the builds fail during the V8 compilation on both Ubuntu Precise and Debian Wheezy. Both were trying to use clang-3.4 because the default compilers that ship with those distros have been too old to compile a modern V8 for some time now.

The builds failed in the same way for Wheezy and Precise, on both 32bit and 64bit architectures. The error message in all cases from clang looked like this:

clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/mark-compact-f6dbed.cpp
clang: note: diagnostic msg: /tmp/mark-compact-f6dbed.sh
clang: note: diagnostic msg: 

********************

I have attached those mark-compact-* files here, gzipped.
mark-compact-f6dbed.sh.gz
mark-compact-f6dbed.cpp.gz

Newer versions of Debian and Ubuntu (which do have gcc new enough to work out of the box) are building just fine.

[chrislea]

Working on getting a full build log @bnoordhuis, please stay tuned.

[chrislea]

Full build log attached @bnoordhuis. This was attempting to build on Ubuntu Precise, amd64, with clang 3.4. However, the errors look the same in all the contexts where I saw the builds die. Please let me know if there's any additional details I can provide.

precise-6.5.0-clang-3.4-build.log.gz

[jbergstroem]

Stops with:

  /usr/bin/clang++ '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_I18N_SUPPORT' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_TRANSLITERATION=1' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' '-DUCONFIG_NO_LEGACY_CONVERSION=1' '-DUCONFIG_NO_CONVERSION=1' -I../deps/v8 -I../deps -I../deps/icu/source/i18n -I../deps/icu/source/common  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /build/nodejs-6.5.0/out/Release/.deps//build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/constant-array-builder.o.d.raw -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -c -o /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/constant-array-builder.o ../deps/v8/src/interpreter/constant-array-builder.cc
0  libLLVM-3.4.so.1 0x00002b77ff46be92 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1  libLLVM-3.4.so.1 0x00002b77ff46c229
2  libpthread.so.0  0x00002b7800144cb0
3  clang            0x000000000119cbe2 clang::Expr::EvaluateAsInitializer(clang::APValue&, clang::ASTContext const&, clang::VarDecl const*, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >&) const + 82
4  clang            0x0000000001139591 clang::VarDecl::evaluateValue(llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >&) const + 209
5  clang            0x000000000113f649 clang::VarDecl::checkInitIsICE() const + 345
6  clang            0x0000000000ade33a clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) + 1754
7  clang            0x0000000000b76643 clang::Sema::ActOnExprStmt(clang::ActionResult<clang::Expr*, true>) + 67
8  clang            0x000000000091910b clang::Parser::ParseExprStatement() + 107
9  clang            0x0000000000912e0f clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 3103
10 clang            0x000000000091300d clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, bool, clang::SourceLocation*) + 141
11 clang            0x0000000000913bcf clang::Parser::ParseCompoundStatementBody(bool) + 1743
12 clang            0x00000000008f665a clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) + 1546
13 clang            0x00000000008f7ddd clang::Parser::ParseLambdaExpression() + 397
14 clang            0x00000000008e4239 clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) + 7113
15 clang            0x00000000008e551d clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) + 29
16 clang            0x00000000008e65df clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 31
17 clang            0x00000000008e682d clang::Parser::ParseExpressionList(llvm::SmallVectorImpl<clang::Expr*>&, llvm::SmallVectorImpl<clang::SourceLocation>&, void (clang::Sema::*)(clang::Scope*, clang::Expr*, llvm::ArrayRef<clang::Expr*>), clang::Expr*) + 221
18 clang            0x00000000008e9177 clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*, true>) + 759
19 clang            0x00000000008e275b clang::Parser::ParseCastExpression(bool, bool, bool&, clang::Parser::TypeCastState) + 235
20 clang            0x00000000008e551d clang::Parser::ParseCastExpression(bool, bool, clang::Parser::TypeCastState) + 29
21 clang            0x00000000008e65df clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 31
22 clang            0x00000000008e72f9 clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
23 clang            0x00000000009190e0 clang::Parser::ParseExprStatement() + 64
24 clang            0x0000000000912e0f clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) + 3103
25 clang            0x000000000091300d clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, bool, clang::SourceLocation*) + 141
26 clang            0x0000000000913bcf clang::Parser::ParseCompoundStatementBody(bool) + 1743
27 clang            0x0000000000914073 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) + 195
28 clang            0x00000000008b5a9e clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) + 1534
29 clang            0x000000000091e58b clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 4027
30 clang            0x000000000091f099 clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 681
31 clang            0x000000000091f360 clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 144
32 clang            0x00000000008cb899 clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 841
33 clang            0x00000000008b7f7f clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 639
34 clang            0x00000000008d65bd clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) + 381
35 clang            0x00000000008d721e clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 2958
36 clang            0x00000000008cb90b clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 955
37 clang            0x00000000008b7f7f clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 639
38 clang            0x00000000008d65bd clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*, std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation, std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) + 381
39 clang            0x00000000008d721e clang::Parser::ParseNamespace(unsigned int, clang::SourceLocation&, clang::SourceLocation) + 2958
40 clang            0x00000000008cb90b clang::Parser::ParseDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, unsigned int, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) + 955
41 clang            0x00000000008b7f7f clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) + 639
42 clang            0x00000000008b8792 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 178
43 clang            0x00000000008ae9ad clang::ParseAST(clang::Sema&, bool, bool) + 493
44 clang            0x00000000005c5baa clang::FrontendAction::Execute() + 202
45 clang            0x00000000005a5ead clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 285
46 clang            0x000000000058dd3e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1582
47 clang            0x0000000000587ea8 cc1_main(char const**, char const**, char const*, void*) + 1160
48 clang            0x00000000005865a8 main + 632
49 libc.so.6        0x00002b78008897ed __libc_start_main + 237
50 clang            0x00000000005878d1
Stack dump:
0.  Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name mark-compact.cc -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -g -ffunction-sections -fdata-sections -coverage-file /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/heap/mark-compact.o -resource-dir /usr/bin/../lib/clang/3.4 -dependency-file /build/nodejs-6.5.0/out/Release/.deps//build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/heap/mark-compact.o.d.raw -MT /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/heap/mark-compact.o -D V8_TARGET_ARCH_X64 -D ENABLE_DISASSEMBLER -D V8_I18N_SUPPORT -D V8_IMMINENT_DEPRECATION_WARNINGS -D ICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -D UCONFIG_NO_TRANSLITERATION=1 -D UCONFIG_NO_SERVICE=1 -D UCONFIG_NO_REGULAR_EXPRESSIONS=1 -D U_ENABLE_DYLOAD=0 -D U_STATIC_IMPLEMENTATION=1 -D U_HAVE_STD_STRING=0 -D UCONFIG_NO_BREAK_ITERATION=0 -D UCONFIG_NO_LEGACY_CONVERSION=1 -D UCONFIG_NO_CONVERSION=1 -D _FORTIFY_SOURCE=2 -I ../deps/v8 -I ../deps -I ../deps/icu/source/i18n -I ../deps/icu/source/common -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward -internal-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/../../../../include/x86_64-linux-gnu/c++/4.6 -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.4/include -internal-externc-isystem /usr/bin/../lib/gcc/x86_64-linux-gnu/4.6/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -Wall -Wextra -Wno-unused-parameter -Wformat -Wformat-security -std=gnu++0x -fdeprecated-macro -fdebug-compilation-dir /build/nodejs-6.5.0/out -ferror-limit 19 -fmessage-length 0 -pthread -stack-protector 1 -stack-protector-buffer-size 4 -mstackrealign -fno-rtti -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/heap/mark-compact.o -x c++ ../deps/v8/src/heap/mark-compact.cc 
1.  ../deps/v8/src/heap/mark-compact.cc:3502:65: current parser token '}'
2.  ../deps/v8/src/heap/mark-compact.cc:32:1: parsing namespace 'v8'
3.  ../deps/v8/src/heap/mark-compact.cc:33:1: parsing namespace 'internal'
4.  ../deps/v8/src/heap/mark-compact.cc:3498:71: parsing function body 'UpdatePointersInParallel'
5.  ../deps/v8/src/heap/mark-compact.cc:3498:71: in compound statement ('{}')
6.  ../deps/v8/src/heap/mark-compact.cc:3502:13: lambda expression parsing
7.  ../deps/v8/src/heap/mark-compact.cc:3502:40: in compound statement ('{}')
  /usr/bin/clang++ '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_I18N_SUPPORT' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_TRANSLITERATION=1' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' '-DUCONFIG_NO_LEGACY_CONVERSION=1' '-DUCONFIG_NO_CONVERSION=1' -I../deps/v8 -I../deps -I../deps/icu/source/i18n -I../deps/icu/source/common  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /build/nodejs-6.5.0/out/Release/.deps//build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/control-flow-builders.o.d.raw -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -c -o /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/control-flow-builders.o ../deps/v8/src/interpreter/control-flow-builders.cc
  /usr/bin/clang++ '-DV8_TARGET_ARCH_X64' '-DENABLE_DISASSEMBLER' '-DV8_I18N_SUPPORT' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' '-DUCONFIG_NO_TRANSLITERATION=1' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_STATIC_IMPLEMENTATION=1' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' '-DUCONFIG_NO_LEGACY_CONVERSION=1' '-DUCONFIG_NO_CONVERSION=1' -I../deps/v8 -I../deps -I../deps/icu/source/i18n -I../deps/icu/source/common  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -fno-strict-aliasing -m64 -fdata-sections -ffunction-sections -O3 -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -MMD -MF /build/nodejs-6.5.0/out/Release/.deps//build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/handler-table-builder.o.d.raw -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -c -o /build/nodejs-6.5.0/out/Release/obj.target/v8_base/deps/v8/src/interpreter/handler-table-builder.o ../deps/v8/src/interpreter/handler-table-builder.cc
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)

[bnoordhuis]

@chrislea Thanks. It's hitting an ICE, an internal compiler error. You're using clang 3.4.1 now. Is testing with 3.4.2 an option for you?

If that doesn't fix the issue, we have three options:

1. Revert the V8 upgrade. (I don't think this is really an option but I put it in for completeness.)
2. Tweak mark-compact.cc until it avoids the ICE.
3. Update the minimally supported clang version to 3.5 or 3.6.

[Fishrock123]

I think 3. is out of the question - that's effectively a breaking change.

Revert the V8 upgrade.

Less breaking than 3. at this point.

[chrislea]

@bnoordhuis going to a newer version of clang is not immediately possible, as in, I can't do it in the next 30min. But I can look into it and see how much work will be involved.

[ofrobots]

Why is 3 a breaking change?

[Fishrock123]

We're now failing to compile on mainstream linux distros we previously compiled on...?

[ofrobots]

Yes, but that is not a breaking change for users. People who build packages are impacted, yes, but if we can build a package successfully using either 3.5 that is compatible on that distro, it is not a breaking change.

[ofrobots]

More details from clang:

1.  ../deps/v8/src/heap/mark-compact.cc:3502:65: current parser token '}'
2.  ../deps/v8/src/heap/mark-compact.cc:32:1: parsing namespace 'v8'
3.  ../deps/v8/src/heap/mark-compact.cc:33:1: parsing namespace 'internal'
4.  ../deps/v8/src/heap/mark-compact.cc:3498:71: parsing function body 'UpdatePointersInParallel'
5.  ../deps/v8/src/heap/mark-compact.cc:3498:71: in compound statement ('{}')
6.  ../deps/v8/src/heap/mark-compact.cc:3502:13: lambda expression parsing
7.  ../deps/v8/src/heap/mark-compact.cc:3502:40: in compound statement ('{}')
clang: error: unable to execute command: Segmentation fault (core dumped)

[ofrobots]

Commenting out the lambda line makes the ICE go away. I think we should be able work around this issue by converting the lambda to function. I would still be interested in reports on whether clang 3.4.2 has already fixed this problem.

[ofrobots]

Quick and dirty hacked workaround:

diff --git a/deps/v8/src/heap/mark-compact.cc b/deps/v8/src/heap/mark-compact.cc
index de40fa0..511fc5a 100644
--- a/deps/v8/src/heap/mark-compact.cc
+++ b/deps/v8/src/heap/mark-compact.cc
@@ -3494,12 +3494,24 @@ int NumberOfPointerUpdateTasks(int pages) {
   return Min(kMaxTasks, (pages + kPagesPerTask - 1) / kPagesPerTask);
 }

+// Work-around bug in clang-3.4
+// https://github.com/nodejs/node/issues/8323
+template <PointerDirection direction>
+struct Foo {
+  PageParallelJob<PointerUpdateJobTraits<direction> >& job_;
+  Foo(PageParallelJob<PointerUpdateJobTraits<direction> >& job) : job_(job) {}
+  void operator()(MemoryChunk* chunk) {
+    job_.AddPage(chunk, 0);
+  }
+};
+
 template <PointerDirection direction>
 void UpdatePointersInParallel(Heap* heap, base::Semaphore* semaphore) {
   PageParallelJob<PointerUpdateJobTraits<direction> > job(
       heap, heap->isolate()->cancelable_task_manager(), semaphore);
-  RememberedSet<direction>::IterateMemoryChunks(
-      heap, [&job](MemoryChunk* chunk) { job.AddPage(chunk, 0); });
+  //RememberedSet<direction>::IterateMemoryChunks(
+  //    heap, [&job](MemoryChunk* chunk) { job.AddPage(chunk, 0); });
+  RememberedSet<direction>::IterateMemoryChunks(heap, Foo<direction>(job));
   PointersUpdatingVisitor visitor(heap);
   int num_pages = job.NumberOfPages();
   int num_tasks = NumberOfPointerUpdateTasks(num_pages);

[ofrobots]

I just tried building with clang-3.4.2 without the above workaround, and I no longer see the internal compiler error. I think switching to building w/ 3.4.2 if at all possible is going to be a better solution.

[jbergstroem]

@ofrobots doesn't look like it: http://packages.ubuntu.com/precise/clang-3.4

[bnoordhuis]

Is the argument that we can't bump the requirement to 3.4.2 because precise only ships 3.4.1?

I don't have a problem with that. It only affects the intersection of users that build from source on precise. They can still use the binaries from https://nodejs.org/.

[jbergstroem]

@bnoordhuis I wouldn't call it that, just stating that it doesn't seem to be available and I have no real insight into precise packaging. Can only assume its.. careful.

[chrislea]

Actually, there are other options for Precise. Ubuntu Wheezy is the real problem. I tried all day yesterday to get a sane compiler new enough made for Wheezy that would work and failed in a variety of different ways. I don't think we can do it without a) a lot more work or b) forcing people running Wheezy to upgrade their libstdc++, which I don't want to do. So I think we will have to drop support for Wheezy.

[ofrobots]

So I think we will have to drop support for Wheezy.

That won't be so great to do for v6.x. Let me polish up and PR the diff from https://github.com/nodejs/node/issues/8323#issuecomment-243192053.

Independently, a head's up that Node v7.x will require a more modern compiler toolchain as V8 5.4 has started to depend upon C++11 compiler and runtime features.

[ofrobots]

https://github.com/nodejs/node/pull/8343

[chrislea]

Okay. That may be wise @ofrobots since as far as I can tell, there's a similar situation for Ubuntu Precise (which I know people are actually really running out in the wild). I don't think we can ship this "as is" unless we update libstdc++6 on the target host, which we'd rather avoid obviously.

[misterdjules]

@ofrobots

Independently, a head's up that Node v7.x will require a more modern compiler toolchain as V8 5.4 has started to depend upon C++11 compiler and runtime features.

Do you have more details about this? I think this would be worth opening a separate issue, unless it's been done already.

[ofrobots]

The WIP PR to bring in V8 5.4 is here: https://github.com/nodejs/node/pull/8317 and there some related discussion on https://github.com/nodejs/node/issues/7844 about the next version of ICU also requiring C++11.

[chrislea]

I'm perfectly fine with deprecating support for old Linux distros when V7 happens, but it'll be great to support the ones we've had for V6 for its full lifecycle.

[rvagg]

So ICU's C++ allowance is currently pretty minimal because they are looking for broad compiler support and gcc and clang are out in front compared to other compilers so that's all good. It's V8 that I'm a little concerned about because we've never had the C++ runtime requirement until now. Do we have any idea what the impact of linking against libc++ will be on portability of distributable binaries? And @ofrobots do you have any details on the expanded C++ feature set that they will be allowing so we can pin down minimum compiler versions for v7+?

[rvagg]

FYI there is now a ubuntu1204-clang341-64 build node in the CI mix for clang 3.4.1, we'll see how it goes and we can skip it for v7+ if we're happy to go that way but it'd be good to be able to hold ourselves to our minimum clang like we do for gcc.

[ofrobots]

The compiler toolchain requirements for V8 are 'officially' documented here. I am double-checking with the V8 team that this is up-to-date. The set of C++11 language and runtime features that are permitted to be used on the V8 code-base follow these guidelines. V8 is slightly more conservative in feature use than Chromium as V8 needs to support a larger set of platforms. V8 didn't start use the C++11 runtime features until V8 5.2 IIRC.

we've never had the C++ runtime requirement until now

I think you meant 'C++11 runtime requirement' because otherwise the above is not actually true. Node does need to link with libstdc++ already.

linking against libc++ will be on portability of distributable binaries

For v7.x, linking against libc++ is done on mac only. Apple themselves have deprecated and stopped updating libstdc++ a long time ago (since 10.6) and have switched over to libc++. On 10.9+ libc++ is actually the system default. libc++ is available on 10.7, the minimum Node requires, so binaries are still portable for the versions of mac we support. More context here.

On linux, v7.x will end up requiring a more modern libstdc++ with support for C++11 runtime features in use. This may push on the boundaries of the really old distributions (e.g. precise, wheezy) if they do not have libstdc++ backport packages available.

[Trott]

Apologies if this is an irksomely uninformed question, but I'm unclear on whether the current general sense is that this is expected to be fixable Very Soon or, on the other hand, if this might end up being a complicated issue that results in a reversion to an earlier V8 in Node.js v6.5.1 or later. Can someone indicate?

[ofrobots]

This can be fixable Very Soon if I can get review and sign-off on https://github.com/nodejs/node/pull/8343.

[rvagg]

thanks for the update @ofrobots (and yes C++11 is what I meant), this is helpful info