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.
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.
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.
0.18.1 doesn't build on CentOS 7 with devtoolset-7
centos - How to make devtoolset g++ available for Makefile in docker's centos7? - Unix & Linux Stack Exchange
linux - How to permanently enable newer version of software installed from SCL repo? - Unix & Linux Stack Exchange
Gcc 7.3.1 not available when generating a C++17 Singularity ROOT image
According to the comments and my own experience with Docker, each RUN line is run in a separate shell environment, so when you source an environment in one RUN line, that environment is not available to other RUN commands.
Using the line RUN source scl_source enable devtoolset-7 && cd /home/admin/${APP_NAME}/nginx-base/cplusplus && make version && make instead of your previous RUN command makes sure the current environment is setup for the make command.
As a workaround:
SHELL ["sh", "-c", "source scl_source enable $(scl -l) && sh -c \"$0\" \"$@\""]
it replaces the shell for all following RUN.
In your ~/.bashrc or ~/.bash_profile Simply source the "enable" script provided with the devtoolset. For example, with the Devtoolset 2, the command is:
source /opt/rh/devtoolset-2/enable
or
source scl_source enable devtoolset-2
Lot more efficient: no forkbomb, no tricky shell
An alternative of source /opt/rh/devtoolset-4/enable is
source scl_source enable devtoolset-4
The above shell script scl_source is more elegant than using a hard coded path (may be different on another machine). However scl_source does less because /opt/rh/devtoolset-4/enable uses scl_source and other stuff.
To use scl_source you may have to upgrade package scl-utils
yum update scl-utils # old scl-utils versions miss scl_source
Quick copy-paste
echo 'source scl_source enable devtoolset-4' >> ~/.bashrc
# Do not forget to change the version ↑
Source code for curious people
An example of scl_source source code:
https://gist.github.com/bkabrda/6435016
The scl_source installed on my Red Hat 7.1
#!/bin/bash
_scl_source_help="Usage: source scl_source <action> [<collection> ...]
Don't use this script outside of SCL scriptlets!
Options:
-h, --help display this help and exit"
if [ $# -eq 0 -o $1 = "-h" -o $1 = "--help" ]; then
echo "$_scl_source_help"
return 0
fi
if [ -z "$_recursion" ]; then
_recursion="false"
fi
if [ -z "$_scl_scriptlet_name" ]; then
# The only allowed action in the case of recursion is the same
# as was the original
_scl_scriptlet_name=$1
fi
shift 1
if [ -z "$_scl_dir" ]; then
# No need to re-define the directory twice
_scl_dir=/etc/scl/conf
if [ ! -e $_scl_dir ]; then
_scl_dir=/etc/scl/prefixes
fi
fi
for arg in "$@"; do
_scl_prefix_file=$_scl_dir/$arg
_scl_prefix=`cat $_scl_prefix_file 2> /dev/null`
if [ $? -ne 0 ]; then
echo "Can't read $_scl_prefix_file, $arg is probably not installed."
return 1
fi
# First check if the collection is already in the list
# of collections to be enabled
for scl in ${_scls[@]}; do
if [ 
scl ]; then
continue 2
fi
done
# Now check if the collection isn't already enabled
/usr/bin/scl_enabled $arg > /dev/null 2> /dev/null
if [ $? -ne 0 ]; then
_scls+=($arg)
_scl_prefixes+=($_scl_prefix)
fi;
done
if [ $_recursion == "false" ]; then
_i=0
_recursion="true"
while [ 
{#_scls[@]} ]; do
_scl_scriptlet_path="${_scl_prefixes[$_i]}/${_scls[$_i]}/${_scl_scriptlet_name}"
source "$_scl_scriptlet_path"
if [ $? -ne 0 ]; then
echo "Can't source $_scl_scriptlet_name, skipping."
else
export X_SCLS="${_scls[$_i]} $X_SCLS"
fi;
_i=
_i+1))
done
_scls=()
_scl_prefixes=()
_scl_scriptlet_name=""
_recursion="false"
fi
A work-around that I found is to set gnome-terminal to run
bash -c "$HOME/.bashrc; exec zsh"
as a custom command in place of the default shell, which is equivalent to opening a terminal emulator with
gnome-terminal -- bash -c "$HOME/.bashrc; exec zsh"
adapted from here.
It seems you could also use:
source /opt/rh/devtoolset-8/enable
Tested on RHEL7.6 for package rh-php73, it worked:
source /opt/rh/rh-php73/enable
Found the hint here
I just found a way to do this.
The key is to use a third-party tool which allows fish-shell source command read bash scripts. I use bass.
After installing bass, you can simply use bass source scl_source enable devtoolset-7
to change gcc version. You can also add it to ~/.config/fish/config.fish so that it takes effect everytime you log in.
More discussion here.
You can add commands in /etc/fish/config.fish
# Put system-wide fish configuration entries here
# or in .fish files in conf.d/
# Files in conf.d can be overridden by the user
# by files with the same name in $XDG_CONFIG_HOME/fish/conf.d
# This file is run by all fish instances.
# To include configuration only for login shells, use
# if status --is-login
# ...
# end
# To include configuration only for interactive shells, use
# if status --is-interactive
# ...
# end
source scl_source enable rh-git29
source scl_source enable rh-postgresql10
using scl enable actually opens a new shell inside your current one, which is quite unclean, especially if done from a login script.
You should place, instead, in your ~/.bash_profile:
source /opt/rh/rh-nginx18/enable
or:
source scl_source enable rh-nginx18
The latter is more "elegant" as it is independent from the actual installation path.
This has the effect of loading the environment in your current shell.
Redhat proposes placing a file in /etc/profile.d, i.e. for python:
$ cat /etc/profile.d/enablepython33.sh
#!/bin/bash
source scl_source enable python33
As this works for the devtools under centos for me you could try this.