On Tue, May 5, 2020 at 11:54 PM Rob McDonald <[email protected]> wrote:
> > My user who recently had problems because my app developed a dependency on > std::regexp -- which isn't really supported by gcc 4.8. The problem is > less the compiler and more the standard libraries installed on the > machine. He is not building on the big machine -- he builds on a local vm > on a laptop and then transfers the binary up. They also prefer to do their > local setup on images that are as similar as possible to the computation > environment. Perhaps they could set up local compilers and libraries, but > that is a much bigger hassle than using system installed standard libraries. > For Redhat, Developer Toolset ( https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/7.0_release_notes/dts7.0_release) provides a newer compiler environment using the "scl enable devtoolset-X <command>" mechanism. We've recently switched to C++11 as a minimum standard, and you're correct that gcc 4.8 isn't up to the job. Fortunately, so far devtoolset has worked fine. I certainly understand the value to large customers of stability, but even for them the costs of maintaining code tied to an older standard grow ever greater over time. As the broader community moves on and your available pool of contributors trained to (and willing to!) develop in older coding environments shrinks, you gradually lose the synergies of community which are such an important part of open source (or even software development in general.) We've generally been pretty conservative about upgrading standards, but we finally reached a point where the difficulty of implementation and maintaining significant user features without the support of modern C/C++ was so great compared to the job of setting up something like developer tool-set that we could no longer justify sinking the time and effort into accommodating the limitations of the C89/C++98 standards. Cheers, CY
