Skip to content

Conversation

seishun
Copy link
Contributor

@seishun seishun commented Apr 1, 2018

Currently CentOS 6 machines use gcc 4.8 while Node.js requires "gcc and g++ 4.9.4 or newer". See #762.

devtoolset-3 has gcc 4.9.1, too old.
devtoolset-5 has "gcc (GCC) 5.3.1 20160406", that's still older than gcc 4.9.4.
devtoolset-6 has "gcc (GCC) 6.3.1 20170216", good enough.

The CERN repo doesn't have devtoolset newer than 2, so I replaced that with Software Collections, just like in #809.

@rvagg
Copy link
Member

rvagg commented Apr 2, 2018

  1. we can't apply this to the release-*centos6* machines that build Node >4<10, they are stuck on devtoolset-2
  2. if we apply it to our test-*centos6* machines then we won't have a config that matches our Node >4<10 release binaries for testing

So we need a strategy where we can use both.

Can you investigate whether we can have two different devtoolset's installed on a host and then just switch PATH according to version? That would be easy to do as long as they can coexist on the same host.

@seishun
Copy link
Contributor Author

seishun commented Apr 2, 2018

we can't apply this to the release-centos6 machines that build Node >4<10, they are stuck on devtoolset-2

Why? Hasn't this previously been applied to release machines without issues? (#809)

Can you investigate whether we can have two different devtoolset's installed on a host and then just switch PATH according to version?

Seems to work fine, but what should JENKINS_PATH contain, then?

@rvagg
Copy link
Member

rvagg commented Apr 2, 2018

The release machines haven't been touched, they can't be, a new devtoolset is going to bring in a new libstdc++ and mess up our binaries (haven't tested in this particular case so I may be wrong about how devtoolsets impact the shipped binaries).

Let's leave JENKINS_PATH empty and amend PATH in Jenkins to switch between the two.

@seishun
Copy link
Contributor Author

seishun commented Apr 2, 2018

The release machines haven't been touched, they can't be, a new devtoolset is going to bring in a new libstdc++ and mess up our binaries (haven't tested in this particular case so I may be wrong about how devtoolsets impact the shipped binaries).

Devtoolsets don't impact the binaries, see #809 (comment) and #797 (comment).

Let's leave JENKINS_PATH empty and amend PATH in Jenkins to switch between the two.

Alright, I don't really care as long as it doesn't significantly prolong the process. Should I just delete the JENKINS_PATH= lines and the PATH=$JENKINS_PATH part?

@rvagg
Copy link
Member

rvagg commented Apr 2, 2018

yeah, you might have to leave this with me, the init.d script doesn't match what we have deployed right now, that JENKINS_PATH stuff is in /etc/sysconfig/jenkins rather than directly in the script and it doesn't have the ccache directory in it either so I'm going to have to work out how we have a delta here.

@mhdawson
Copy link
Member

mhdawson commented Apr 3, 2018

As a note using 4.9.4 on PPCLE broke the ability for releases to run on RHEL72. Not sure if that will be the same on x86 but we may want to validate before switching over. I had to backout the change for 8.X on PPCLE.

@sam-github
Copy link
Contributor

Can be reopened if its still relevant, but I think its stale.

@sam-github sam-github closed this Jan 28, 2020
@seishun seishun deleted the centos6-gcc49 branch January 28, 2020 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants