Red Hat Enterprise Linux, being an "enterprise" operating system, is designed to be stable and similar for a long time. That means you do not get the "latest and greatest" by default, but a known-good implementation that remains the default on that particular RHEL version for the long term. Generally you only get substantial software upgrades by upgrading RHEL. Unfortunately, there is no RHEL 8 yet.
devtoolset allows you to switch to newer, out-of-band versions of development software like GCC, in a way that doesn't "contaminate" the whole OS installation. I used it, with great success, to get GCC 4.8 (and its C++11 support) on CentOS 6, where the official GCC is 4.4.
devtoolset-8 has GCC 8.2.1.
Or you could choose to use a distribution more suited for home users, such as Fedora.
Or you could download the GCC source and build it yourself (but ew!).
Answer from Lightness Races in Orbit on Stack OverflowWhy RHEL 8 is shipping with Linux Kernel 4.18 and GCC 8.2?
Generally speaking with any Red Hat releases software, you can’t look only at upstream version number comparisons, but instead also need to look at the errata to see what has been patched. RH will keep versions steady for a long period of time, but will “back-port” bugs. This means if something relevant was fixed in the latest kernel, and it doesn’t break functionality in GCC 8.2, then RH has the ability to port the fix back to the RHEL 8 kernel version.
GCC is of particular note because RH made the realization years ago that although keeping GCC constant helps with enterprise compatibility needed by their customers, developers hate missing out on newer features. This is why RH offers the Software Collections channel, so that the latest dev tools can be pulled down and used.
More on reddit.comrhel - How to install gcc 9.X on RHEL8? - Unix & Linux Stack Exchange
yum - How to install newer GCC version in RHEL 8 - Unix & Linux Stack Exchange
Will there be backward compatible compilers in RHEL 9
Red Hat Enterprise Linux, being an "enterprise" operating system, is designed to be stable and similar for a long time. That means you do not get the "latest and greatest" by default, but a known-good implementation that remains the default on that particular RHEL version for the long term. Generally you only get substantial software upgrades by upgrading RHEL. Unfortunately, there is no RHEL 8 yet.
devtoolset allows you to switch to newer, out-of-band versions of development software like GCC, in a way that doesn't "contaminate" the whole OS installation. I used it, with great success, to get GCC 4.8 (and its C++11 support) on CentOS 6, where the official GCC is 4.4.
devtoolset-8 has GCC 8.2.1.
Or you could choose to use a distribution more suited for home users, such as Fedora.
Or you could download the GCC source and build it yourself (but ew!).
One can surely build the gcc on CentOS oneself(though ew!).
Generally follow the below steps:
sudo yum -y update
sudo yum -y install bzip2 wget gcc gcc-c++ gmp-devel mpfr-devel libmpc-devel make
gcc --version
wget http://mirrors-usa.go-parts.com/gcc/releases/gcc-8.2.0/gcc-8.2.0.tar.gz
tar zxf gcc-8.2.0.tar.gz
mkdir gcc-8.2.0-build
cd gcc-8.2.0-build
../gcc-8.2.0/configure --enable-languages=c,c++ --disable-multilib
make -j 2
sudo make install
gcc --version
At this point, many can not see 8.2, i.e.
gcc version 4.8.5 (GCC)
Just overwrite the old gcc with which just built, i.e.
# which gcc
/usr/local/bin/gcc
# cp gcc/xgcc /usr/local/bin/gcc
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-unknown-linux-gnu/7.2.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-7.2.0/configure --enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 7.2.0 (GCC)
In order to avoid library error, one may need update libstdc as well,
cp ./aarch64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 /usr/local/lib64/libstdc++.so.6
cp ./stage1-aarch64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 /usr/lib64/libstdc++.so.6
One may also update libc.so as well, i.e. 2.18
curl -O http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz
tar zxf glibc-2.18.tar.gz
cd glibc-2.18/
mkdir build
cd build/
../configure --prefix=/usr
make -j2
make install
ln -sf /usr/glibc-2.18/glibc-2.18.so /lib64/libc.so.6
Finally, type /lib64/libc.so.6 to confirm
Mostly, ln would fail, since old relations, and LD is suggested, i.e.
LD_LIBRARY_PATH=/usr/glibc-2.18/lib
export LD_LIBRARY_PATH
First, sorry if my question sounds more like a complaint from some very uneducated random user. I'm really not an expert indeed, but I'm aware that version 4.18 of the Linux kernel ceased to be supported upstream for very long now. Also GCC 8.3 came out much longer before RHEL 8 was released. Since I've always been told that systems like RHEL are mainly focused on servers, data centers and mission critical tasks in general.. what is the rationale behind the choice of which version to include? Isn't GCC 8.2 much "buggier" than 8.3? Shouldn't it be wiser for such a system to ship with less buggy software in the first place? Thanks for your patience and time.
Generally speaking with any Red Hat releases software, you can’t look only at upstream version number comparisons, but instead also need to look at the errata to see what has been patched. RH will keep versions steady for a long period of time, but will “back-port” bugs. This means if something relevant was fixed in the latest kernel, and it doesn’t break functionality in GCC 8.2, then RH has the ability to port the fix back to the RHEL 8 kernel version.
GCC is of particular note because RH made the realization years ago that although keeping GCC constant helps with enterprise compatibility needed by their customers, developers hate missing out on newer features. This is why RH offers the Software Collections channel, so that the latest dev tools can be pulled down and used.
You can't say 8.2 is much "buggier" than 8.3 just because you've found more bugs there. How do /you/ calculate "buggy-ness"? Bugs are found over time and use, so I have mental model that includes a time component, and a use component. Also, some bugs are worse than others.
All software has bugs. A bug is a "problem", and all problems are complex entities having different impact based on their environment and manner of occurrence, and many other factors. Moving from a bug count to a quantification of a particular version of software's value can be.. subjective, I suppose. Complicated.
Currently there is only gcc-11.2 available in the repo of RHEL 9 Beta. Is there any plan from Redhat to ship some other backward compatible gcc compilers (gcc-8.5, gcc-toolset-9, etc. included in RHEL 8), or only newer versions will be introduced into RHEL 9 appstream? It will be of great convenient to have such packages and fulfill compilation requirements of old stuff like CUDA.
Which version of g++ is supported on 8.4 almalinux ? Also is there a way we can install multiple devtoolset from EPEL repo on this vertsion of Alma linux? I am more specifically interested in devtoolset 8 and boost 1.75