Use gcc 4.9.4 in CI

@bnoordhuis

Now that nodejs/node#13466 has landed, we need to make sure all our boxes have the newer compiler levels.

According to @bnoordhuis in nodejs/node#13466 (comment), binaries built with the later version should run everywhere they did before, so there shouldn't be a problem just updating the level on all our boxes.

I'd assume most/all of our older machines are using gcc 4.8.4.

This might be a good time to test out our ansible scripts.

I would like to work on this, but I couldn't find documentation on how this whole thing works and how I can test it locally. I would be grateful if someone can point me in the right direction.

/cc @nodejs/build

@seishun

@seishun old ansible scripts are in setup/, new ones are in ansible/, we're trying to move over to the new scripts, but they're not completely tested yet.

The README in the ansible directory should have the info you need to get started, and the scripts should be documented. If you run into any issues with it let us know.

@gibfahn

@gibfahn I'm a complete noob here, would https://github.com/nodejs/build/blob/master/setup/TESTING_LOCALLY.md still work for testing new scripts?

@seishun

@seishun I tried to follow the guides once but got distracted... You doing it for the first time is a good chance to document missing pieces and hidden assumption, so it would be great if you open a doc PR or pass the info to me and I'll PR it.

@seishun

@seishun in theory yes. Actually that document should really be ported over to ansible/.

@refack

There are 5 remaining platforms in CI with outdated gcc:

centos7-64. This should be simple, just need to figure out if the ansible/ scripts work well for CentOS 7 or the old scripts in setup/ should be changed instead.
rhel72-s390x. It's not listed in ansible/roles/baselayout/vars/main.yml, so presumably it was deployed using setup/rhel72-linuxonecc. I'm also not sure how one can test the changes. @refack mentioned that you can get trial access here - will that work?
aix61-ppc64. Same as above - is setup/aix61 the right script? Is there any way I can test this?
cc-armv6 and cc-armv7. These two run on a machine called node-msft-cross-compiler-1, which is absent in both ansible/inventory.yml and setup/ansible-inventory. Which OS does it run? Are there Ansible scripts for it?

@jBarz

For rhel72-s390x, @jBarz is working on this. The problem is that new ansible templates were created which did not included full support for all platforms. The old templates were, still are used to deploy to the existing machines. Please don't update without co-ordinating with @jBarz
For aix61-ppc64 - I think @gibfahn is looking into that, please don't update without co-ordinating with him.

@jBarz

For rhel72-s390x, @jBarz is working on this.
For aix61-ppc64 - I think @gibfahn is looking into that

Are there issues for tracking these?

@jBarz

AIX is coverd in #925

rhel72-s390x, possibly not, I more recently asked jBarz to start working on that. @jBarz can you open an issue for tracking the work on linuxOne.

Done for linuxOne #1023

@seishun

@seishun about the cross compiler, there is a PR that never landed: #244

Support for Wheezy ends on 31st May 2018, I assume it will be dropped in Node 10. Jessie seems to have gcc 4.9.2 in the repos, can that compile V8 6.5?

But we are stuck with it for previous versions of Node, we need to be careful not to drop support for distros, compilers and libc that we are still going to be shipping in 4, 6, 8 even if we're moving to deprecating them for future versions. We are running Wheezy on the Pi1 and Pi2's and so far have no plan to migrate to Jessie for them. I'm not really happy with this push to move our compiler versions up without a solid plan to continue to test and support our older LTS branches that we have locked in minimum libc version commitments to.

But we are stuck with it for previous versions of Node, we need to be careful not to drop support for distros, compilers and libc that we are still going to be shipping in 4, 6, 8 even if we're moving to deprecating them for future versions. We are running Wheezy on the Pi1 and Pi2's and so far have no plan to migrate to Jessie for them.

Is there an issue with upgrading gcc on the Pi3s and leaving the Pi1s and Pi2s as-is?

I'm not really happy with this push to move our compiler versions up without a solid plan to continue to test and support our older LTS branches that we have locked in minimum libc version commitments to.

Can you suggest a better plan, then?

I gave those a try locally and they seem to work, but they can't compile V8 6.5.

What was the error?

The error is exactly the same as the one in nodejs/node-v8#35. Strange thing there is that it happens while compiling native code, but I tried it in a machine with gcc 5.4.0 and it still happens.

Then it was a bug in V8 that has been fixed upstream: nodejs/node-v8#35 (comment).

Status update. cc-armv6 and cc-armv7 now use gcc 4.9 on master and node-test-commit-arm-fanned successfully builds a commit that requires gcc 4.9.

There are now 5 platforms in CI that require a compiler upgrade:

centos7-arm64. I asked about it in Use gcc 4.9.4 in CI #762 (comment) but didn't get a response. cc @nodejs/build
centos6-64. This is unexpected because it was upgraded in ansible: use gcc 4.9 on CentOS 6 #809. Did someone revert the changes?
centos7-64. This is a simple change in the Ansible scripts if Duplicate 'centos7' in the init dictionary #1034 is resolved.
rhel72-s390x. Waiting for linuxOne: gcc upgrade #1023.
aix61-ppc64. Waiting for AIX: gcc upgrade requirement #925.

@rvagg

Per #1150 (comment), the CentOS 6 machines were redeployed using ansible/ scripts that still install an old gcc version. This is surprising because they previously didn't work (#801) and the offending lines haven't been fixed. Though it's alluded to in #1076, which does seem to fix #801.

Can someone confirm the above? I would be glad to update the ansible/ scripts to install a newer gcc version, but it seems I'll have to wait until #1076 lands. cc @rvagg

I've converted one of the two release Raspberry Pis to the new Docker setup and have this in ci-release (covers most *nix's, not just the Pis):

exec_cmd="make -j $JOBS binary-upload \
  DESTCPU=\"$DESTCPU\" \
  ARCH=\"$ARCH\" \
  DISTTYPE=\"$disttype\" \
  DATESTRING=\"$datestring\" \
  COMMIT=\"$commit\" \
  CUSTOMTAG=\"$CUSTOMTAG\" \
  RELEASE_URLBASE=\"$RELEASE_URLBASE\" \
  CONFIG_FLAGS=\"$CONFIG_FLAGS\" \
"

if [[ "$NODE_LABELS" =~ pi1-docker ]]; then
  echo "$exec_cmd" > node-ci-exec
  if test $NODE_MAJOR_VERSION -ge 10; then
    sudo docker-node-exec.sh -v jessie
  else
    sudo docker-node-exec.sh -v wheezy
  fi
else
  sh -c "$exec_cmd"
fi

So v10+ will build under Jessie, which has 4.9.2 but 9 and prior will be with Wheezy which is 4.8. Trying it out now with the latest nightly but there's quite a cache to build up for Jessie now so it'll be slow for a couple of days.

@seishun

@seishun yeah, I used ansible/ to redeploy a whole new set of centos6 machines iirc. it should work with that PR but there's an outstanding issue with ARCH & DESTCPU that's still outstanding. I'll work to get that resolved but you should be able to assume that it'll get merged in almost the form that it's in now and you're welcome to build on top of it with updates. Remember though that we are building releases with centos6 so we still need to be able to support older compilers too. It'd be good if we could have two variations, one for old and one for new, and we can apply them as appropriate. I don't really like the idea of having to have double the number of CentOS6 machines but perhaps we can do compiler selection in the Jenkins job like the PPC jobs do now.

Remember though that we are building releases with centos6 so we still need to be able to support older compilers too.

Wasn't that discussed back and forth in #797 and #809? Binaries produced by devtoolset work just fine on vanilla OSs, so there is no need to build LTS with gcc 4.8 specifically. For instance, #809 (comment) and #797 (comment).

Just want to mention that building with 4.9.4 broke compatibility for RHEL 7.X for PPCLE, not sure if that is the case for X86 as well ....

In the end I went back to using 4.8 for 9.X and lower and set it to use 4.9.X for 10 and higher.

Looks like every platform now uses gcc 4.9 or newer on master: https://ci.nodejs.org/job/node-test-commit/17876/

At least one job (node-cross-compile) uses a gcc version older than 4.9.4 (4.9.3 specifically), but it seems it would take significant effort to use a newer version there, and it's probably not worth it.

I think this issue can be closed now.

@rvagg

At least one job (node-cross-compile) uses a gcc version older than 4.9.4 (4.9.3 specifically), but it seems it would take significant effort to use a newer version there, and it's probably not worth it.

@rvagg did it: #1237

I believe this has been resolved by installing GCC-6 and documenting in e6a71a0

Navigation Menu

Repository navigation

Use gcc 4.9.4 in CI #762

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Use gcc 4.9.4 in CI #762

Description

Activity

seishun commented on Jun 17, 2017

gibfahn commented on Jun 17, 2017

seishun commented on Jun 17, 2017

refack commented on Jun 17, 2017

gibfahn commented on Jun 17, 2017

seishun commented on Nov 29, 2017

mhdawson commented on Nov 29, 2017

seishun commented on Nov 30, 2017

mhdawson commented on Nov 30, 2017

jBarz commented on Dec 1, 2017

joaocgreis commented on Dec 7, 2017

15 remaining items

rvagg commented on Jan 24, 2018

seishun commented on Jan 27, 2018

joaocgreis commented on Jan 30, 2018

seishun commented on Jan 30, 2018

seishun commented on Mar 30, 2018

seishun commented on Mar 30, 2018

rvagg commented on Mar 31, 2018

rvagg commented on Apr 1, 2018

seishun commented on Apr 1, 2018

mhdawson commented on Apr 3, 2018

mhdawson commented on Apr 3, 2018

seishun commented on Apr 19, 2018

joaocgreis commented on Apr 20, 2018

refack commented on Jun 2, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions