Moving from CentOS to Ubuntu
btorpey.github.io
btorpey.github.io
This is much easier to solve in CentOS and RHEL than building new tools. Redhat has done this for you. If you are a developer and need newer build tools, enable the SCLO repo.
yum install centos-release-scl && yum install devtoolset-9
Or devtoolset-8, whichever has the versions of tools you need. Then in your build script or global environment script, use PATH="/opt/rh/devtoolset-9/root/bin:${PATH}"
scl_source enable devtoolset-9
To get an idea of what versions of tools are in which devtoolsets, visit a repo mirror [1].[1] - http://mirror.centos.org/centos-7/7/sclo/x86_64/rh/Packages/...
- RH devtoolset doesn't support clang, only gcc
-The compilers installed with the devtoolset packages on RH/CentOS 6 & 7 do not support the _GLIBCXX_USE_CXX11_ABI flag -- the old ABI (COW strings) is the only one supported. See https://bugzilla.redhat.com/show_bug.cgi?id=1546704 and https://stackoverflow.com/questions/50836145/glibcxx-use-cxx... for more info.
scl_source enable llvm-toolset-7
though I can't speak to any workarounds for the _GLIBCXX_USE_CXX11_ABI flag.I'm also not sure I've bought in to the way the devtoolset stuff works, by swapping symlinks around. AFAICT that means that only one version is available at any given time.
If you build and install your own tools, you can (and should) install them in a non-standard location -- once you do that, it's relatively simple to support multiple versions at the same time.
Although if it wasn't for the COW vs. SSO strings problem, I would have spent more time on the devtoolset approach, but the lack of true C++11-style strings was a deal-breaker for me. I would much prefer not to be building compilers, although once you've done it once, it's not too bad.