Install devtoolset-7 on Rocky

Rocky Linux Help & Support
1

I recently changed from CentOS 7 (GCC version 7.3.1.) to Rocky 8.5 (GCC version 8.5.0). When I compile C++ code with GCC on Rocky and want to execute it on another system with CentOS 7 I get the following errors:

./program: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./program)
./program: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./program)
./program: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./program)
./program: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./program)

Is it somehow possible to install older version of gcc-toolset or devtoolset on Rocky? For example devtoolset-7 to use it for compiling C++ code?

2

Another toolset will not help, because the issue is in system library. Compare output of:
rpm -q --provides -f /lib64/libstdc++.so.6
on CentOS 7 and Rocky 8. That is, the features provided by package ‘libstdc++’.

When you compile, you do link the executable against dynamic libraries that are in the system and their features are recorded in the executable.

One way around that is static linking. You tell linker to insert all necessary library object code into the executable (from *.a versions of libraries.) Then that executable should not depend on any dynamic linking. Alas, everything can’t link statically, executable becomes large, and there might still be incompatibility with OS/kernel.

If you would package your application as RPM-package, then you probably could build it (with mock) for “CentOS 7” target platform, even on your Rocky.

A recent hype are containers. User creates/uses container that has the executable and the versions of libraries that it needs. Names like podman, singularity, docker, flatpak, snap.

Perhaps, rather than distributing your executable for/as containers, you could build in “CentOS 7” container (or VM)? (The mock seems to use that approach.)

1 Like
3

I had a similar question recently; in the context of rpmbuild, is it possible to build an el7 package on an el8 computer?

4

Mock | A ‘simple’ chroot build environment manager for building RPMs. writes:

Mock is a tool for building packages. It can build packages for different architectures and different Fedora, RHEL, and Mageia versions than the build host have. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot.

Mock is a rpmbuild(8) wrapper. Mock tries to simplify some steps, which would otherwise be boring or complicated.

In other words: it should be.

5

devtoolset is an artifact of EL7, it has been replaced by modules in EL8. That said, there is no module that provides GCC7. If you want to build programs in Rocky Linux 8 that can be run in CentOS 7 the recommended way is to use mock, which has the ability to create binary packages for different targets including CentOS 7.

6

Regarding Mock.
Is it in the official RHEL 8.5 dnf packages? If it’s not, I’m guessing it’s not supported by RH. It’s interesting that it can build different “targets”, I’m not sure how it does this, unless it has big repos built in, or access to remote repos.
Perhaps a better question would be, can you rpmbuild packages for el7 from an el8 machine using only official packages.

7

Mock is in EPEL 8. It has config for each target that it can build for. For example, the config for “centos-7-x86_64” contains same repo definitions (base, updates, extras) as genuine CentOS 7 does. (mirrorlist=http://mirrorlist.centos.org/?release=7&...)

You can do all that manually – create chroot, give dnf custom config, etc.
You do run mock as regular user.

8

That’s interesting about how you can connect it to el7 repos and that it’s in EPEL.
Looks like a good technology.

9

There is more! You don’t actually need to build the packages in your system.
You can do it in Copr https://copr.fedorainfracloud.org/

1 Like
10

Mock, for whatever reason has always been in epel. But consider that (1) Red Hat almost certainly uses it in one stage or another to build packages internally and (2) nothing you build will be supported by Red Hat regardless of which tools you use. At the end of the day, if you build it you support it.

Another thing to keep in mind is that mock comes highly recommended and is used by packagers, pretty much everywhere because it creates a pristine chroot environment for the build, which installs a standard set of buildroot packages plus whatever is specified in as BuildRequires in the spec file for your package, and the build is always reproducible in that way.

1 Like