Chapter 4. Additional toolsets for development

Red Hat Enterprise Linux 8 introduces the GCC Toolset, a compiler toolset that provides a variety of development and performance analysis tools. GCC Toolset is similar to Red Hat Developer Toolset.

GCC Toolset is available as an Application Stream in the form of a software collection in the AppStream repository. GCC Toolset is fully supported under Red Hat Enterprise Linux Subscription Level Agreements, is functionally complete, and is intended for production use. Applications and libraries provided by the GCC Toolset do not replace the Red Hat Enterprise Linux system versions, do not override them, and do not automatically become default or preferred choices. Using a framework called software collections, an additional set of developer tools is installed into the /opt/ directory and is explicitly enabled by the user on-demand by using the scl utility. Unless noted otherwise for specific tools or features, the GCC Toolset is available for all architectures supported by Red Hat Enterprise Linux.

For information about the length of support, see Red Hat Enterprise Linux Application Streams Life Cycle.

Installing the GCC Toolset on a system installs the main tools and all necessary dependencies. Note that some parts of the toolset are not installed by default and must be installed separately.

To install only certain tools from the GCC Toolset instead of the whole toolset, list the available packages and install the selected ones with the yum package management tool. Use selective installation to access packages not installed by default with the full toolset.

To remove the GCC Toolset from your system, uninstall it by using the yum package management tool.

To access the GCC Toolset, you can run a specific tool using the scl utility, or start a shell session where the toolset versions override the system versions.

GCC Toolset 9 provides the following tools and versions.

The GNU Compiler Collection (GCC) in the GCC Toolset 9 supports multiple C++ language standards.

Using the C++14 language version is supported when all C++ objects compiled with the appropriate flag have been built using GCC version 6 or later.

Using the C++11 language version is supported when all C++ objects compiled with the appropriate flag have been built using GCC version 5 or later.

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 9 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-9 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-9 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 9 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-9 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-9 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

GCC Toolset 10 provides the following tools and versions.

The GNU Compiler Collection (GCC) in the GCC Toolset can use the following C++ standards:

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 10 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-10 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-10 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 10 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-10 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-10 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

GCC Toolset 11 provides the following tools and versions.

The GNU Compiler Collection (GCC) in the GCC Toolset can use the following C++ standards:

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 11 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-11 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-11 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 11 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-11 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-11 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

GCC Toolset 12 provides the following tools and versions.

The GNU Compiler Collection (GCC) in the GCC Toolset can use the following C++ standards:

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 12 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-12 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 12 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-12 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-12 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

Under some circumstances, due to a synchronization issue between annobin and gcc in the GCC Toolset 12, your compilation can fail with an error message that looks similar to the following:

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

To work around the problem, create a symbolic link in the plugin directory from the annobin.so file to the gcc-annobin.so file:

Replace architecture with the architecture you use in your system:

GCC Toolset 13 provides the following tools and versions.

The GNU Compiler Collection (GCC) compiler in the GCC Toolset can use the following C++ standards:

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 13 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-13 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 13 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-13 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-13 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

Under some circumstances, due to a synchronization issue between annobin and gcc in the GCC Toolset 13, your compilation can fail with an error message that looks similar to the following:

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

To work around the problem, create a symbolic link in the plugin directory from the annobin.so file to the gcc-annobin.so file:

Replace architecture with the architecture you use in your system:

GCC Toolset 14 provides the following tools and versions.

The GNU Compiler Collection (GCC) in the GCC Toolset can use the following C++ standards:

All of the language standards are available in both the standard compliant variant or with GNU extensions.

When mixing objects built by using the GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), the GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by the GCC Toolset are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 14 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-14 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-14 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 14 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-14 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

$ scl enable gcc-toolset-14 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

Builds that use the GCC Toolset 14 and annobin can fail due to a synchronization issue between the annobin plugin and gcc. This causes the compiler to fail locating the gcc-annobin.so plugin file.

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

To work around the problem, create a symbolic link in the plugin directory from the annobin.so file to the gcc-annobin.so file:

Replace architecture with the architecture you use in your system:

The GCC Toolset 15 offers updated versions of development tools for building and debugging applications on Red Hat Enterprise Linux 8.

The GNU Compiler Collection (GCC) Toolset 15 supports multiple C++ language standards. The default is C++17, with options for C++98, C++11, C++14, and experimental versions such as C++20, C++23, and C++26.

The GCC compiler in the GCC Toolset 15 can use the following C++ standards:

Using the C++14 language version is supported when all C++ objects compiled with the appropriate flag have been built using GCC version 6 or later.

This is the default language standard setting for the GCC Toolset 15, with GNU extensions, equivalent to explicitly using option -std=gnu++17.

Using the C++17 language version is supported when all C++ objects compiled with the appropriate flag have been built using GCC version 10 or later.

To enable the C++20 standard, add the command-line option -std=c++20 to your g++ command line.

To enable the C++23 standard, add the command-line option -std=c++23 to your g++ command line.

To enable the C++26 standard, add the command-line option -std=c++26 to your g++ command line. All of the language standards are available in both the standard compliant variant or with GNU extensions.

Use the GCC Toolset 15 for linking when you combine objects built by using the GCC Toolset 15 with objects built by using the system toolchain, particularly .o or .a files. This ensures any newer library features provided only by the GCC Toolset 15 are resolved at link time.

Certain behaviors and requirements of the GCC Toolset 15 differ from the base Red Hat Enterprise Linux GNU Compiler Collection (GCC). These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-15 'gcc -lsomelib objfile.o'

Using a library from the GCC Toolset 15 in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice and specify the option by adding the library after the options specifying the object files:

+

$ scl enable gcc-toolset-15 'gcc objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC.

Certain behaviors and requirements of binutils in the GCC Toolset 15 differ from the base Red Hat Enterprise Linux binutils. These include automatic static linking of certain library features and the requirement to specify libraries after object files during linking.

$ scl enable gcc-toolset-15 'ld -lsomelib objfile.o'

Using a library from the GCC Toolset 15 in this manner results in the linker error message undefined reference to symbol. To prevent this problem, follow the standard linking practice, and specify the option adding the library after the options specifying the object files:

+

$ scl enable gcc-toolset-15 'ld objfile.o -lsomelib'

Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils.

Builds that use the GCC Toolset 15 and annobin can fail due to a synchronization issue between the annobin plugin and gcc. This causes the compiler to fail locating the gcc-annobin.so plugin file.

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-15/root/usr/lib/gcc/_architecture_-linux-gnu/15/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

To work around the issue, create a symbolic link in the plugin directory from annobin.so to gcc-annobin.so:

Replace architecture with the architecture used on your system:

Tools versions provided in the GCC Toolset 14 container image match the GCC Toolset 14 components versions.

To access and run the GCC Toolset container image, use a standard container engine like Podman. Authenticate with the registry, pull the image, and launch a container to access an isolated, pre-configured toolchain for development.

To pull and start using the GCC Toolset 14 Toolchain container image, access the registry, pull the image, and launch it.

The gcc-toolset-15 container image provides a GCC Toolset 15 toolchain for building, testing, and troubleshooting C and C++ applications on Red Hat Enterprise Linux (RHEL). By using this image, you can maintain a reproducible environment without installing packages directly on the host.

The image is part of the RHEL container collection. All included RPM packages originate from official RHEL repositories, ensuring the image follows standard RHEL lifecycle and support policies. This provides a portable, containerized alternative to traditional RPM-based delivery.

Deployment scenarios include:

The gcc-toolset-15 image targets the same architectures provided by Red Hat Enterprise Linux (RHEL), including AMD64 and Intel 64 (x86_64), 64-bit ARM (aarch64), IBM Power, little endian (ppc64le), and 64-bit IBM Z (s390x).

For image-specific metadata, supported architectures, and tags, see the Red Hat container catalog entry for the gcc-toolset-15 container image.

If you plan to deploy the image across multiple architectures, ensure that you choose a tag that includes multi-architecture support or use architecture-specific tags according to your organization’s standards.

The gcc-toolset-15 image is available from Red Hat container registries. The exact path can differ depending on whether you use public registries, internal mirrors, or both. Placeholders for image locations are used below:

Use your product documentation, internal image catalog, or registry UI to determine the correct values for <REGISTRY>, <NAMESPACE>, and <TAG>. Record these values for use in the procedures that follow.

To configure hosts to use the gcc-toolset-15 image, verify system requirements and install necessary container tools. For comprehensive guidelines, see Building, running, and managing containers.

To pull the gcc-toolset-15 image, you must log in to the container registry.

To use the gcc-toolset-15 image, pull it to your local system after authenticating to the registry.

To use the gcc-toolset-15 image for interactive development, run an interactive container that mounts source code from the host.

To perform noninteractive builds, run the gcc-toolset-15 image with a predefined build script that exits upon completion.

In CI systems, you can integrate this pattern by running podman run as part of a pipeline step. Use pipeline variables or configuration files to provide the values for <REGISTRY>, <NAMESPACE>, <TAG>, and host paths.

Ensure build scripts write logs and artifacts to host-mounted directories. This practice enables CI systems and administrators to inspect outputs after the container exits and to archive them as needed.

To maintain the gcc-toolset-15 image, monitor for updates including security fixes, bug fixes, and dependency changes. Track updates and errata by monitoring RHEL release notes, or internal advisories for new images that contain updated GCC Toolset 15 content.

Identify and resolve common issues when pulling or running the gcc-toolset-15 container image.

The output should display a table row containing the repository, tag, image ID, and size. For example:

REPOSITORY                            TAG     IMAGE ID      CREATED     SIZE
registry.redhat.io/.../gcc-toolset-15 latest  a1b2c3d4e5f6  2 days ago  540MB

Review the following operational and security guidelines when using the gcc-toolset-15 container image in your environment.

The following section describes how to:

The following section describes how to use annocheck to examine:

Under some circumstances, due to a synchronization issue between annobin and gcc in the GCC Toolset 12, your compilation can fail with an error message that looks similar to the following:

cc1: fatal error: inaccessible plugin file
opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin/gcc-annobin.so
expanded from short plugin name gcc-annobin: No such file or directory

To work around the problem, create a symbolic link in the plugin directory from the annobin.so file to the gcc-annobin.so file:

Replace architecture with the architecture you use in your system: