3

I have a relatively old server with CentOS 6 on it. The default gcc is 4.4.7 but after some googling, I found I can update this via devtoolset-7. I installed devtoolset-7 via root (i.e. sudo -i), and it installed okay.

Then I did scl enable devtoolkit-7 bash but it dosn't seem to do anything.

[affan@abm-lab ~]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[affan@abm-lab ~]$ scl enable devtoolset-7 bash

[affan@abm-lab ~]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Does anyone know why scl is not enabling a sub environment with the proper variables set?

masfenix
  • 141
  • 1
  • 4
  • Try some system call tracing: run `strace -e trace=file,process,desc scl enable devtoolset-7 bash` and try to track down what it might be trying to do. – qneill Mar 10 '20 at 18:10

2 Answers2

5

I had this problem as well. I don't know why scl was failing to enable the environment, but I was able to get it to load with source /opt/rh/devtoolset-7/enable.

user561726
  • 51
  • 1
3

It is because of your settings in .bashrc and/or .bash_profile. scl appends its path to gcc7 before starting your new bash shell, but the path to gcc is default to the old gcc4 again because your .bashrc appends /usr/bin to the path when starting the new bash, and it supersedes the scl settings. The solution is to use the "enable" script directly. That way no further path settings annoy you.

Xenapior
  • 31
  • 1