On Mon, Dec 14, 2020 at 02:36:20PM -0500, Serguei Mokhov wrote:
> >
> > I have done this in the past with mixed success, typical problems
> > include "cmake is too old", "autoconf/autotools are too old".
> 
> Having run into this at a smaller scale for one of the projects I ended up using
> devtoolset-6 (and -7 as appropriate) that ships all this stuff such as
> newer GCC,
> GLIBC, etc.
> 

Yes, devtoolset is the advertised solution. I bought into it myself,
and then got burned after discovering that is it is missing one critical
32-bit shared library and it cannot be used to cross-compile 32-bit executables,
a "must have" for a couple of experiments that use hardware
with 600-1200 MHz Pentium-3 processors. (replacement hardware is in the USD$5000
price ranges, quantity "to be upgraded" is around 10, none of this has
been budgeted and 64-bit upgrade is not needed for the function
they perform).

Anyhow, is there commitment to devtoolset updates to c++17, c++20, c++21, etc?

For our MIDAS Data Acquisition package, we just started using c++11 recently,
and already we desire to use c++14 and c++17 features. (cannot, because of el7).

Then, there is the question whether SL7 "upgraded to latest versions of everything"
is still SL7. ("grand father's axe", etc). For a purist, SL7 is something
installed from an official installer image, adding packages from EPEL and ELREPO
starts pushing it. SL7 with custom-built linux kernel, glibc, sshd, httpd, kde,
php100 and python3000 is probably not SL7 anymore.

The label "SL7" is only useful if it refers to something well defined. If every
instance of SL7 has a different linux kernel, different versions of devtoolset,
different cmake, different python, etc, I would say SL7 no longer exists.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada