doc: update minimum g++ version to 4.9.4

[bnoordhuis]

The 4.8.x releases don't fully support C++11. Update the prerequisites
for node.js 8 so that we won't have to work around compiler bugs in the
future.

To be decided if we should also update the minimum clang version.
I believe clang 3.4.2 properly supports C++11 but am not 100% sure.

Refs: #11840

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

[tniessen]

Docs: "Clang 3.3 and later implement all of the ISO C++ 2011 standard." I did not try to build with clang 3.3/3.4.2 though.

[gibfahn]

Which number is the clang version here?

➜ ~ ❯ clang --version ~ Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin 

 ~ $ clang --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64- apple-darwin14.0.0 Thread model: posix 

[bnoordhuis]

There is only a tenuous correspondence between apple-clang's version numbers and upstream clang. For OS X, we should just say "latest xcode (or xcode command line tools) or bust."

[tniessen]

@gibfahnLLVM 3.6.0svn should be the LLVM / clang version for your second snippet. No idea regarding the first one, probably something newer.

[gibfahn]

For OS X, we should just say "latest xcode (or xcode command line tools) or bust."

I guess the question is whether if you install the command line tools on an older macOS level you still get the latest version.

But in general that makes sense.

[rvagg]

We're still stuck on 4.8.2 for CentOS6/EL6, both test and release builds (have been for a while so I don't know why our stated minimum is newer than what we actually use). This comes out of devtoolset-2 from the scientificlinux repos. Any thoughts on how we go about getting a better gcc on EL6 without too much pain?

[rvagg]

devtoolset-3-gcc.x86_64 : GCC version 4.9 devtoolset-3-gcc-c++.x86_64 : C++ support for GCC version 4.9 

Looks like we get devtoolset-3 on EL6 without anything special, so we could just switch to that instead of the hoops we jump through for devtoolset-2.

Does anyone know of any potentially breaking reasons that we might not want to switch from gcc 4.8 to gcc 4.9 for the Node.js 8 binaries that we ship? Would this be a disruption to users in any way?

[gibfahn]

Am I right in thinking that the libstdc++ dependency comes from gcc?

[bnoordhuis]

I guess the question is whether if you install the command line tools on an older macOS level you still get the latest version.

I think the answer is yes if it's a supported (by Apple) version of OS X / macOS.

Am I right in thinking that the libstdc++ dependency comes from gcc?

Correct. Per https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html:

GCC 4.8.0: libstdc++.so.6.0.18 GCC 4.8.3: libstdc++.so.6.0.19 GCC 4.9.0: libstdc++.so.6.0.20 

libstdc++6 releases are always forward-compatible and compatible with the previous one unless otherwise noted (which isn't the case for these three.)

[gibfahn]

libstdc++6 releases are always forward-compatible and compatible with the previous one unless otherwise noted (which isn't the case for these three.)

So these are all compatible, and there's no issue right (somewhat confused by the double negative)?

[bnoordhuis]

They are not incompatible, no. :-)

[refack]

Like 👍

[refack]

How about adding a parenthetical (on macOS - latest xcode or xcode command line tools)

[mhdawson]

LGTM

[seishun]

Yes please. This is blocking #13676.

[jasnell]

@bnoordhuis ... I'd like to get this landed but @refack had an outstanding comment: #13466 (comment)

[refack]

@bnoordhuis ... I'd like to get this landed but @refack had an outstanding comment: #13466 (comment)

Non blocking suggestion.

[bnoordhuis]

Added note, PTAL.

[chrislea]

I've got an unhealthy amount of info in my head about what Linux distros will be affected by this change and in what ways, so I thought I'd try and summarize that info here for people to see. As expected only older distros are affected, sometimes in different ways. Some are "easy to fix", which I define as "there is an easily installable new compiler toolchain available that doesn't cause any other issues when installed". I'll go from least problematic to most.

NO ISSUES

All supported version of Fedora
Debian Stretch, Buster, Sid
Ubuntu Xenial, Zappus

EASY TO DEAL WITH

CentOS 6 / CentOS 7 / RHEL6 / RHEL7 via devtoolset-6
Ubuntu Trusty for Intel Chips via clang-3.5

UNSURE HOW TO DEAL WITH BUT FEEL OKAY IGNORING

Debian Wheezy
Ubuntu Trusty for ARM Chips (can't compile openssl with clang on ARM)

ACTUAL PROBLEM PRACTICALLY SPEAKING

Debian Jessie

Jessie is a special case for a few reasons.

1. Tons of people run it
2. Most Raspberry Pi boards are running Raspbian which is Jessie

Now, Jessie ships with gcc = 4.9.2. So if any release from the 4.9.x series will work and we don't actually need exactly 4.9.4, then this is a non-issue. But, if we really do need 4.9.4, then this is a real issue that will affect a lot of people that I think will have a reasonable expectation that they can run the most up-to-date versions of Node.

Obviously let me know if there's any additional questions or info I can provide.

[bnoordhuis]

@chrislea Useful info, thanks.

As to the gcc version, 4.9.2 should work (and will probably continue to work) but I didn't want to get in a situation like we did with clang, where we had to float an intrusive patch to work around a bug in 3.4.1 that was fixed in 3.4.2.

[refack]

@chrislea et al. Will it give us more wiggle room, if we build each dep with a different toolset? (If that's possible and not harmful)?
I think I can break GYPs spirit and make it support that...
Ref: Should we continue to support FreeBSD? #14384

[AdamMajer]

FYI, default compiler for SLES12 is still gcc 4.8.5 although gcc6 is also available. SLE11SP4 only seems to have 5.3.1 available, with default gcc being 4.3

[chrislea]

Okay, thanks for the replies.

@bnoordhuis I think based on your comment that we're probably safe to assume 4.9.2 is "okay" for now. I will look into seeing if I can make 4.9.4 packages for Jessie to get around the potential issue that you mention that we saw with clang, but it's probably not too likely we'll see that.

@refack I'm not entirely sure what you're asking. We (NodeSource) currently build distro packages with toolsets native to each distro, so we're already using different toolsets and have been forever.

[refack]

I'm not entirely sure what you're asking. We (NodeSource) currently build distro packages with toolsets native to each distro, so we're already using different toolsets and have been forever.

I mean decompose the build, for example, build openSSL with gcc, V8 with clang, and tie them together with cc...

[guillaume-lin]

I am using cent os 7 and gcc 4.8.2, when compile node 8.9.1, it just warn me but not stop me from compile node. does this mean it is safe for me to compile node 8.9.1 with gcc 4.8.2 ?

[tniessen]

@guillaume-lin Just because something is not officially supported does not mean it is impossible, it just means that if you have any problems with your builds, you are on your own and most likely won't receive any support from us. Note that even if you manage to compile node using an outdated (and unsupported) compiler, this is no guarantee for the correctness, quality and / or performance of the resulting binary. We strongly recommend to use an up-to-date toolchain to compile node.