Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update minimum g++ version to 4.9.4 #13466

Closed
wants to merge 2 commits into from

Conversation

bnoordhuis
Copy link
Member

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)

@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. labels Jun 5, 2017
@tniessen
Copy link
Member

tniessen commented Jun 5, 2017

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
Copy link
Member

gibfahn commented Jun 5, 2017

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
Copy link
Member Author

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
Copy link
Member

tniessen commented Jun 5, 2017

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

@gibfahn
Copy link
Member

gibfahn commented Jun 5, 2017

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
Copy link
Member

rvagg commented Jun 5, 2017

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
Copy link
Member

rvagg commented Jun 5, 2017

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
Copy link
Member

gibfahn commented Jun 5, 2017

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

@bnoordhuis
Copy link
Member Author

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
Copy link
Member

gibfahn commented Jun 5, 2017

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
Copy link
Member Author

They are not incompatible, no. :-)

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like 👍

BUILDING.md Outdated
@@ -76,7 +76,7 @@ Depending on host platform, the selection of toolchains may vary.

Prerequisites:

* `gcc` and `g++` 4.8.5 or newer, or
* `gcc` and `g++` 4.9.4 or newer, or
* `clang` and `clang++` 3.4.2 or newer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@seishun seishun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please. This is blocking #13676.

@seishun seishun mentioned this pull request Jun 14, 2017
2 tasks
@jasnell
Copy link
Member

jasnell commented Jun 14, 2017

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

@refack
Copy link
Contributor

refack commented Jun 14, 2017

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

Non blocking suggestion.

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: nodejs#11840
@bnoordhuis
Copy link
Member Author

Added note, PTAL.

addaleax added a commit that referenced this pull request Jun 24, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
rvagg pushed a commit that referenced this pull request Jun 29, 2017
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.

PR-URL: #13466
Ref: #11840
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Nikolai Vavilov <[email protected]>
addaleax added a commit that referenced this pull request Jun 29, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax added a commit that referenced this pull request Jun 29, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax added a commit that referenced this pull request Jun 30, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax added a commit that referenced this pull request Jun 30, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax added a commit that referenced this pull request Jul 3, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax pushed a commit that referenced this pull request Jul 11, 2017
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.

PR-URL: #13466
Ref: #11840
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Michael Dawson <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Nikolai Vavilov <[email protected]>
addaleax added a commit that referenced this pull request Jul 11, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`23d41f3118`](2abaa86ba8)]
    [#13466](#13466)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`2bb6614904`](8506acc1b5)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`30bc9dc20f`](30bc9dc20f)]
    [#13137](#13137)

* **V8**
  * The V8 engine has been upgraded to version 5.9, which has a significantly
    changed performance profile.
    [#13515](#13515)

PR-URL: #13744
addaleax added a commit that referenced this pull request Jul 18, 2017
Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`820b011ed6`](820b011ed6)]
    [#13466](#13466)

* **Cluster**
  * Users now have more fine-grained control over the inspector port used by
    individual cluster workers. Previously, cluster workers would simply
    increment from the master's debug port.
    [[`dfc46e262a`](dfc46e262a)]
    [#14140](#14140)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`ebe7bb29aa`](ebe7bb29aa)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`6e30e2558e`](6e30e2558e)]
    [#13137](#13137)

* **npm**
  * The `npm` CLI has been updated to version 5.3.0. In particular, it now comes
    with the `npx` binary, which is also shipped with Node.
    [[`dc3f6b9ac1`](dc3f6b9ac1)]
    [#14235](#14235)
  * `npm` Changelogs:
      - [v5.0.4](https://github.com/npm/npm/releases/tag/v5.0.4)
      - [v5.1.0](https://github.com/npm/npm/releases/tag/v5.1.0)
      - [v5.2.0](https://github.com/npm/npm/releases/tag/v5.2.0)
      - [v5.3.0](https://github.com/npm/npm/releases/tag/v5.3.0)

PR-URL: #13744
Fishrock123 added a commit to Fishrock123/node that referenced this pull request Jul 19, 2017
Big thanks to @addaleax who prepared the vast majority of this release.

Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`820b011ed6`](nodejs@820b011ed6)]
    [nodejs#13466](nodejs#13466)

* **Cluster**
  * Users now have more fine-grained control over the inspector port used by
    individual cluster workers. Previously, cluster workers would simply
    increment from the master's debug port.
    [[`dfc46e262a`](nodejs@dfc46e262a)]
    [nodejs#14140](nodejs#14140)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`ebe7bb29aa`](nodejs@ebe7bb29aa)]
    [nodejs#13723](nodejs#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`6e30e2558e`](nodejs@6e30e2558e)]
    [nodejs#13137](nodejs#13137)

* **npm**
  * The `npm` CLI has been updated to version 5.3.0. In particular, it now comes
    with the `npx` binary, which is also shipped with Node.
    [[`dc3f6b9ac1`](nodejs@dc3f6b9ac1)]
    [nodejs#14235](nodejs#14235)
  * `npm` Changelogs:
      - [v5.0.4](https://github.com/npm/npm/releases/tag/v5.0.4)
      - [v5.1.0](https://github.com/npm/npm/releases/tag/v5.1.0)
      - [v5.2.0](https://github.com/npm/npm/releases/tag/v5.2.0)
      - [v5.3.0](https://github.com/npm/npm/releases/tag/v5.3.0)

PR-URL: nodejs#13744
Fishrock123 added a commit that referenced this pull request Jul 19, 2017
Big thanks to @addaleax who prepared the vast majority of this release.

Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`820b011ed6`](820b011ed6)]
    [#13466](#13466)

* **Cluster**
  * Users now have more fine-grained control over the inspector port used by
    individual cluster workers. Previously, cluster workers would simply
    increment from the master's debug port.
    [[`dfc46e262a`](dfc46e262a)]
    [#14140](#14140)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`ebe7bb29aa`](ebe7bb29aa)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`6e30e2558e`](6e30e2558e)]
    [#13137](#13137)

* **npm**
  * The `npm` CLI has been updated to version 5.3.0. In particular, it now comes
    with the `npx` binary, which is also shipped with Node.
    [[`dc3f6b9ac1`](dc3f6b9ac1)]
    [#14235](#14235)
  * `npm` Changelogs:
      - [v5.0.4](https://github.com/npm/npm/releases/tag/v5.0.4)
      - [v5.1.0](https://github.com/npm/npm/releases/tag/v5.1.0)
      - [v5.2.0](https://github.com/npm/npm/releases/tag/v5.2.0)
      - [v5.3.0](https://github.com/npm/npm/releases/tag/v5.3.0)

PR-URL: #13744
Fishrock123 added a commit that referenced this pull request Jul 19, 2017
Big thanks to @addaleax who prepared the vast majority of this release.

Notable changes:

* **Async Hooks**
  * Multiple improvements to Promise support in `async_hooks` have been made.

* **Build**
  * The compiler version requirement to build Node with GCC has been raised to
    GCC 4.9.4.
    [[`820b011ed6`](820b011ed6)]
    [#13466](#13466)

* **Cluster**
  * Users now have more fine-grained control over the inspector port used by
    individual cluster workers. Previously, cluster workers would simply
    increment from the master's debug port.
    [[`dfc46e262a`](dfc46e262a)]
    [#14140](#14140)

* **DNS**
  * The server used for DNS queries can now use a custom port.
    [[`ebe7bb29aa`](ebe7bb29aa)]
    [#13723](#13723)
  * Support for `dns.resolveAny()` has been added.
    [[`6e30e2558e`](6e30e2558e)]
    [#13137](#13137)

* **npm**
  * The `npm` CLI has been updated to version 5.3.0. In particular, it now comes
    with the `npx` binary, which is also shipped with Node.
    [[`dc3f6b9ac1`](dc3f6b9ac1)]
    [#14235](#14235)
  * `npm` Changelogs:
      - [v5.0.4](https://github.com/npm/npm/releases/tag/v5.0.4)
      - [v5.1.0](https://github.com/npm/npm/releases/tag/v5.1.0)
      - [v5.2.0](https://github.com/npm/npm/releases/tag/v5.2.0)
      - [v5.3.0](https://github.com/npm/npm/releases/tag/v5.3.0)

PR-URL: #13744
@chrislea
Copy link

chrislea commented Jul 25, 2017

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
Copy link
Member Author

@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.

@bnoordhuis bnoordhuis deleted the update-gcc-prereq-8 branch July 26, 2017 09:13
@refack
Copy link
Contributor

refack commented Jul 26, 2017

@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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

refack commented Jul 31, 2017

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
Copy link

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
Copy link
Member

tniessen commented Dec 3, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. notable-change PRs with changes that should be highlighted in changelogs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.