compilers: install GCC 8 /CLANG 7 (as V8 does)

[refack]

Chromium and V8 are actually build with a very recent revision off the LLVM dev branch (svn revision 344066 which is ver 8 that is in progress)

GCC 8.1 has been available since May 2018 (http://gnu.mirrors.pair.com/gcc/gcc-8.1.0/) with 8.2 the latest.
CLang 7 has been available since Sep 2018 (http://releases.llvm.org/).
We are already using a very advanced MSVC compiler.

Using the latest compiler includes the latest optimizers, which is free performance gain. It also enables new C++ language fatures which can make the code simpler, and safer.

As I see it we need to make sure we can do this, then recommend an update to core.

/CC @nodejs/build @nodejs/release

[targos]

/cc @hashseed who told me that V8 is currently blocked by us because we still support GCC 4.9. They would like to start using C++14 features for which support was added in GCC 5

[nschonni]

Is this for 11? Otherwise what is the impact for native add-on building if introduced in 10

[refack]

Is this for 11? Otherwise what is the impact for native add-on building if introduced in 10

This will probably be for 12.

[hashseed]

Whether it's Node 11 or Node 12 is not particularly relevant for V8, since we take a snapshot of the master branch from time to time to use for our CI.

[mhdawson]

@gdams FYI, need to figure out plan for newer compiler on IBM platforms.

[rvagg]

I think we should probably start making moves in this direction for master for Node 12. #1583 is about release builds, I think devtoolset-7 might make sense on CentOS 7 for that. But we'll need to assess what we can do across our Linux test cluster, I'm sure there are going to be awkward edges.

For instance, Debian Stable (stretch) doesn't come with gcc-8, it's queued in Testing & Unstable. Thankfully Ubuntu 18.04 has it though.

[refack]

For instance, Debian Stable (stretch) doesn't come with gcc-8, it's queued in Testing & Unstable. Thankfully Ubuntu 18.04 has it though.

I'm more concerned with the IBM machines. It might be worth considering switching to clang for those, as it seems LLVM is easier to bootstrap.

[rvagg]

clang might be easier in lots of places, https://apt.llvm.org/ is pretty helpful. We'd need to balance that against needing to have gcc compilability tested though unless we're prepared to say gcc isn't a Tier 1 supported compiler.

[refack]

We can just barely still say that since it's not for V8...

[hashseed]

We still have a bot that tests building with GCC. We would love to get rid of it though :)

[mhdawson]

I don't think we'd want to change just the IBM machines to clang. I'd like them to be building in a similar manner to the other Linux machines where possible.

[refack]

I don't think we'd want to change just the IBM machines to clang.

We could decide to use clang on every platform where GCC8 is not available. IIUC Google has already built clang for many of those platforms, maybe we could use it's binaries.

BTW I'm also working on enabling clang on Windows (at least for testing, and to make V8's life easier).

[refack]

Platform breakdown:

• CentOS on amd64 - devtoolset-8 available for CentOS 6 (and 7) - https://developers.redhat.com/blog/2018/11/13/gcc-8-2-ga-rhel/#more-536557
• Ubuntu
  • Xenial - 8.1 backport available for all of our platforms - http://ppa.launchpad.net/jonathonf/gcc-8.1/ubuntu/dists/xenial/main/
  • Bionic - official version available - https://packages.ubuntu.com/search?keywords=gcc-8
• SmartOS - GCC 7 available for SmartOS17 (Are better available 8 for 16/17?)
• AIX - GCC8.1 available - https://www.ibm.com/developerworks/aix/library/aix-toolbox/date.html
• musl - GCC8.2 available for Alpine >=3.9 - https://pkgs.alpinelinux.org/packages?name=gcc&branch=v3.9

[ThePrez]

Addition to @refack's platform breakdown:

• IBM i - GCC6.3.0 available :-(

[mhdawson]

Based on the discussion here: nodejs/node#25082 we would only need GCC 5.x or higher.

[mhdawson]

I'm thinking we should target gcc 6.x for 12.x if we upgrade. If it support C++ 14.x from nodejs/node#25082 its sounds like that is all that we would need.

[refack]

Based on the discussion in the last meeting of the BuildWG consensus is that we'll target GCC-6 as the minimum, but strive to use latest (easily) available version for the release of 12.

@mhdawson is my understanding correct?

[mhdawson]

@refack as you mention the agreement was to target GCC-6 as the minimum and but use later versions were possible on the release machines.

That does mean though that we must have testing for GCC-6 for all platforms to validate we are properly supporting the minimum in addition to testing for what we use on the release machines.

[refack]

Let me see if I understand... So for example:
Ubuntu 14 (trusty) should have 4.9 (for LTS) 6 (for minimum) and 8 (for release)
node 10,11 - release and test with 4.9
node 12 - release and test with 8 and test with 6

(BTW we could run the 6 test only daily as it's covered by the limited platforms)

[mhdawson]

Ubuntu 14 (trusty) should have 4.9 (for LTS) 6 (for minimum) and 8 on platforms where we use it to release. This might be zero for Ubuntu 14 as we use centos to release on x86 and as per other discussions we may not use gcc 8 for PPC releases

I don't think we properly cover 6 by running it only nightly. From our discussion what I understood is that for x64 we would be able to test on both 6 and 8 in regression runs as we already run tests on 2 levels of the compiler.

[refack]

@rvagg do you remember why we made "partially static build" only an opt in option (i.e. nodejs/node#4152)?

Beside the ~10% size increase of the binary, it seems like that will solve most of our OS/Compiler interoperability woes.

Refs: https://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas

[rvagg]

@refack no, but it may be about historical drift toward more and more libstdc++ usage. There was a time when this wasn't a problem but V8 lead us in to stdc++ usage and we followed. So it could simply be a matter of managing around compatibility without stepping aside and making a strategic decision for it. Making it opt-out might be a good thing to propose.
I wonder if there's a way that this might mess with loading addons though?

[refack]

Triggered by an observation made by @rvagg I've tracked down some insight into a way for us to verify backwards compatibility of our binaries.

For binary:

1. Find library dependencies of the binary:

   > objdump -p out/Release/node
    Version References:
      required ...
      required from libstdc++.so.6:
        ...
        0x0297f870 0x00 06 GLIBCXX_3.4.20
        ...
      required from libc.so.6:
        0x06969197 0x00 26 GLIBC_2.17

For target OS:

1. figure out the location of target system's lib location, e.g. for libstdc++:

   > ldconfig  -p | grep libstdc++
        libstdc++.so.6 (libc6,64bit) => /lib64/libstdc++.so.6
        libstdc++.so.6 (libc6) => /lib/libstdc++.so.6

2. print it's symbols:

   > strings /lib64/libstdc++.so.6 | grep LIBC`
    ...
    GLIBCXX_3.4.19
    ...
    GLIBCXX_LDBL_3.4.10
    ...
    GLIBC_2.4
    ...
    GLIBCXX_DEBUG_MESSAGE_LENGTH

3. if "violations" are detected, they can be tracked down to the offending symbol:

   > objdump -x out/Release/node | grep GLIBCXX_3.4.20 |  c++filt
    000000000153f688       F *UND*  0000000000000000              std::__throw_out_of_range_fmt(char const*, ...)@@GLIBCXX_3.4.20

Refs: https://stackoverflow.com/questions/4133674/glibcxx-versions
Refs: https://akkadia.org/drepper/dsohowto.pdf

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is remove or a comment is made.

[mhdawson]

We have another issue to agree on the baseline tools for 14.x so I think this can be closed, let me know if don't think that was the right thing to do.