Chapter 4. Additional toolsets for development 4.1. Using GCC Toolset 4.1.1. What is GCC Toolset Red Hat Enterprise Linux 8 introduces GCC Toolset, an Application Stream containing more up-to-date versions of development and performance analysis tools. GCC Toolset is similar to Red Hat Developer Toolset for RHEL 7. 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 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 using the scl utility. Unless noted otherwise for specific tools or features, 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 . 4.1.2. Installing GCC Toolset Installing 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. Procedure To install GCC Toolset version N : 4.1.3. Installing individual packages from GCC Toolset To install only certain tools from GCC Toolset instead of the whole toolset, list the available packages and install the selected ones with the yum package management tool. This procedure is useful also for packages that are not installed by default with the toolset. Procedure List the packages available in GCC Toolset version N : To install any of these packages: Replace package_name with a space-separated list of packages to install. For example, to install the gcc-toolset-13-annobin-annocheck and gcc-toolset-13-binutils-devel packages: 4.1.4. Uninstalling GCC Toolset To remove GCC Toolset from your system, uninstall it using the yum package management tool. Procedure To uninstall GCC Toolset version N : 4.1.5. Running a tool from GCC Toolset To run a tool from GCC Toolset, use the scl utility. Procedure To run a tool from GCC Toolset version N : 4.1.6. Running a shell session with GCC Toolset GCC Toolset allows running a shell session where the GCC Toolset tool versions are used instead of system versions of these tools, without explicitly using the scl command. This is useful when you need to interactively start the tools many times, such as when setting up or testing a development setup. Procedure To run a shell session where tool versions from GCC Toolset version N override system versions of these tools: 4.1.7. Additional resources Red Hat Developer Toolset User Guide 4.2. GCC Toolset 9 Learn about information specific to GCC Toolset version 9 and the tools contained in this version. 4.2.1. Tools and versions provided by GCC Toolset 9 GCC Toolset 9 provides the following tools and versions: Table 4.1. Tool versions in GCC Toolset 9 Name Version Description GCC 9.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 8.3 A command-line debugger for programs written in C, C++, and Fortran. Valgrind 3.15.0 An instrumentation framework and a number of tools to profile applications in order to detect memory errors, identify memory management problems, and report any use of improper arguments in system calls. SystemTap 4.1 A tracing and probing tool to monitor the activities of the entire system without the need to instrument, recompile, install, and reboot. Dyninst 10.1.0 A library for instrumenting and working with user-space executables during their execution. binutils 2.32 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. elfutils 0.176 A collection of binary tools and other utilities to inspect and manipulate ELF files. dwz 0.12 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. make 4.2.1 A dependency-tracking build automation tool. strace 5.1 A debugging tool to monitor system calls that a program uses and signals it receives. ltrace 0.7.91 A debugging tool to display calls to dynamic libraries that a program makes. It can also monitor system calls executed by programs. annobin 9.08 A build security checking tool. 4.2.2. C++ compatibility in GCC Toolset 9 Important The compatibility information presented here apply only to the GCC from GCC Toolset 9. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This is the default language standard setting for GCC Toolset 9, with GNU extensions, equivalent to explicitly using option -std=gnu++14 . Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 9. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 9. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17, C++2a These language standards are available in GCC Toolset 9 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using these standards cannot be guaranteed. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.2.3. Specifics of GCC in GCC Toolset 9 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.2.4. Specifics of binutils in GCC Toolset 9 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.3. GCC Toolset 10 Learn about information specific to GCC Toolset version 10 and the tools contained in this version. 4.3.1. Tools and versions provided by GCC Toolset 10 GCC Toolset 10 provides the following tools and versions: Table 4.2. Tool versions in GCC Toolset 10 Name Version Description GCC 10.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 9.2 A command-line debugger for programs written in C, C++, and Fortran. Valgrind 3.16.0 An instrumentation framework and a number of tools to profile applications in order to detect memory errors, identify memory management problems, and report any use of improper arguments in system calls. SystemTap 4.4 A tracing and probing tool to monitor the activities of the entire system without the need to instrument, recompile, install, and reboot. Dyninst 10.2.1 A library for instrumenting and working with user-space executables during their execution. binutils 2.35 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. elfutils 0.182 A collection of binary tools and other utilities to inspect and manipulate ELF files. dwz 0.12 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. make 4.2.1 A dependency-tracking build automation tool. strace 5.7 A debugging tool to monitor system calls that a program uses and signals it receives. ltrace 0.7.91 A debugging tool to display calls to dynamic libraries that a program makes. It can also monitor system calls executed by programs. annobin 9.29 A build security checking tool. 4.3.2. C++ compatibility in GCC Toolset 10 Important The compatibility information presented here apply only to the GCC from GCC Toolset 10. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This is the default language standard setting for GCC Toolset 10, with GNU extensions, equivalent to explicitly using option -std=gnu++14 . Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 10. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 10. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17 This language standard is available in GCC Toolset 10. C++20 This language standard is available in GCC Toolset 10 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using this standard cannot be guaranteed. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.3.3. Specifics of GCC in GCC Toolset 10 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.3.4. Specifics of binutils in GCC Toolset 10 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.4. GCC Toolset 11 Learn about information specific to GCC Toolset version 11 and the tools contained in this version. 4.4.1. Tools and versions provided by GCC Toolset 11 GCC Toolset 11 provides the following tools and versions: Table 4.3. Tool versions in GCC Toolset 11 Name Version Description GCC 11.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 10.2 A command-line debugger for programs written in C, C++, and Fortran. Valgrind 3.17.0 An instrumentation framework and a number of tools to profile applications in order to detect memory errors, identify memory management problems, and report any use of improper arguments in system calls. SystemTap 4.5 A tracing and probing tool to monitor the activities of the entire system without the need to instrument, recompile, install, and reboot. Dyninst 11.0.0 A library for instrumenting and working with user-space executables during their execution. binutils 2.36.1 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. elfutils 0.185 A collection of binary tools and other utilities to inspect and manipulate ELF files. dwz 0.14 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. make 4.3 A dependency-tracking build automation tool. strace 5.13 A debugging tool to monitor system calls that a program uses and signals it receives. ltrace 0.7.91 A debugging tool to display calls to dynamic libraries that a program makes. It can also monitor system calls executed by programs. annobin 10.23 A build security checking tool. 4.4.2. C++ compatibility in GCC Toolset 11 Important The compatibility information presented here apply only to the GCC from GCC Toolset 11. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This language standard is available in GCC Toolset 11. Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 11. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 11. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17 This language standard is available in GCC Toolset 11. This is the default language standard setting for GCC Toolset 11, 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 respective flag have been built using GCC version 10 or later. C++20 and C++23 This language standard is available in GCC Toolset 11 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using this standard cannot be guaranteed. To enable C++20 support, add the command-line option -std=c++20 to your g++ command line. To enable C++23 support, add the command-line option -std=c++2b to your g++ command line. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.4.3. Specifics of GCC in GCC Toolset 11 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.4.4. Specifics of binutils in GCC Toolset 11 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.5. GCC Toolset 12 Learn about information specific to GCC Toolset version 12 and the tools contained in this version. 4.5.1. Tools and versions provided by GCC Toolset 12 GCC Toolset 12 provides the following tools and versions: Table 4.4. Tool versions in GCC Toolset 12 Name Version Description GCC 12.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 11.2 A command-line debugger for programs written in C, C++, and Fortran. binutils 2.38 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. dwz 0.14 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. annobin 11.08 A build security checking tool. 4.5.2. C++ compatibility in GCC Toolset 12 Important The compatibility information presented here apply only to the GCC from GCC Toolset 12. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This language standard is available in GCC Toolset 12. Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 12. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 12. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17 This language standard is available in GCC Toolset 12. This is the default language standard setting for GCC Toolset 12, 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 respective flag have been built using GCC version 10 or later. C++20 and C++23 This language standard is available in GCC Toolset 12 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using this standard cannot be guaranteed. To enable C++20 support, add the command-line option -std=c++20 to your g++ command line. To enable C++23 support, add the command-line option -std=c++23 to your g++ command line. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.5.3. Specifics of GCC in GCC Toolset 12 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.5.4. Specifics of binutils in GCC Toolset 12 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.5.5. Specifics of annobin in GCC Toolset 12 Under some circumstances, due to a synchronization issue between annobin and gcc in GCC Toolset 12, your compilation can fail with an error message that looks similar to the following: 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: aarch64 i686 ppc64le s390x x86_64 4.6. GCC Toolset 13 Learn about information specific to GCC Toolset version 13 and the tools contained in this version. 4.6.1. Tools and versions provided by GCC Toolset 13 GCC Toolset 13 provides the following tools and versions: Table 4.5. Tool versions in GCC Toolset 13 Name Version Description GCC 13.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 12.1 A command-line debugger for programs written in C, C++, and Fortran. binutils 2.40 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. dwz 0.14 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. annobin 12.32 A build security checking tool. 4.6.2. C++ compatibility in GCC Toolset 13 Important The compatibility information presented here apply only to the GCC from GCC Toolset 13. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This language standard is available in GCC Toolset 13. Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 13. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 13. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17 This language standard is available in GCC Toolset 13. This is the default language standard setting for GCC Toolset 13, 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 respective flag have been built using GCC version 10 or later. C++20 and C++23 These language standards are available in GCC Toolset 13 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using this standard cannot be guaranteed. 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. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.6.3. Specifics of GCC in GCC Toolset 13 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.6.4. Specifics of binutils in GCC Toolset 13 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.6.5. Specifics of annobin in GCC Toolset 13 Under some circumstances, due to a synchronization issue between annobin and gcc in GCC Toolset 13, your compilation can fail with an error message that looks similar to the following: 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: aarch64 i686 ppc64le s390x x86_64 4.7. GCC Toolset 14 Learn about information specific to GCC Toolset version 14 and the tools contained in this version. 4.7.1. Tools and versions provided by GCC Toolset 14 GCC Toolset 14 provides the following tools and versions: Table 4.6. Tool versions in GCC Toolset 14 Name Version Description GCC 14.2.1 A portable compiler suite with support for C, C++, and Fortran. GDB 14.2 A command-line debugger for programs written in C, C++, and Fortran. binutils 2.41 A collection of binary tools and other utilities to inspect and manipulate object files and binaries. dwz 0.14 A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size. annobin 12.70 A build security checking tool. 4.7.2. C++ compatibility in GCC Toolset 14 Important The compatibility information presented here apply only to the GCC from GCC Toolset 14. The GCC compiler in GCC Toolset can use the following C++ standards: C++14 This language standard is available in GCC Toolset 14. Using the C++14 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 6 or later. C++11 This language standard is available in GCC Toolset 14. Using the C++11 language version is supported when all C++ objects compiled with the respective flag have been built using GCC version 5 or later. C++98 This language standard is available in GCC Toolset 14. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8. C++17 This language standard is available in GCC Toolset 14. This is the default language standard setting for GCC Toolset 14, 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 respective flag have been built using GCC version 10 or later. C++20 and C++23 These language standards are available in GCC Toolset 14 only as an experimental, unstable, and unsupported capability. Additionally, compatibility of objects, binary files, and libraries built using this standard cannot be guaranteed. 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. All of the language standards are available in both the standard compliant variant or with GNU extensions. When mixing objects built with GCC Toolset with those built with the RHEL toolchain (particularly .o or .a files), GCC Toolset toolchain should be used for any linkage. This ensures any newer library features provided only by GCC Toolset are resolved at link time. 4.7.3. Specifics of GCC in GCC Toolset 14 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of GCC . 4.7.4. Specifics of binutils in GCC Toolset 14 Static linking of libraries Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk because standard Red Hat Enterprise Linux errata do not change this code. If the need arises for developers to rebuild their applications due to this risk, Red Hat will communicate this using a security erratum. Important Because of this additional security risk, developers are strongly advised not to statically link their entire application for the same reasons. Specify libraries after object files when linking In GCC Toolset, libraries are linked using linker scripts which might specify some symbols through static archives. This is required to ensure compatibility with multiple versions of Red Hat Enterprise Linux. However, the linker scripts use the names of the respective shared object files. As a consequence, the linker uses different symbol handling rules than expected, and does not recognize symbols required by object files when the option adding the library is specified before options specifying the object files: Using a library from 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: Note that this recommendation also applies when using the base Red Hat Enterprise Linux version of binutils . 4.7.5. Specifics of annobin in GCC Toolset 14 Under some circumstances, due to a synchronization issue between annobin and gcc in GCC Toolset 14, your compilation can fail with an error message that looks similar to the following: 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: aarch64 i686 ppc64le s390x x86_64 4.8. Using the GCC Toolset container image Only the two latest GCC Toolset container images are supported. Container images of earlier GCC Toolset versions are unsupported. The GCC Toolset 13 and GCC Toolset 14 components are available in the GCC Toolset 13 Toolchain and GCC Toolset 14 Toolchain container images, respectively. The GCC Toolset container image is based on the rhel8 base image and is available for all architectures supported by RHEL 8: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z 4.8.1. GCC Toolset container image contents Tools versions provided in the GCC Toolset 14 container image match the GCC Toolset 14 components versions . The GCC Toolset 14 Toolchain contents The rhel8/gcc-toolset-14-toolchain container image consists of the following components: Component Package gcc gcc-toolset-14-gcc g++ gcc-toolset-14-gcc-c++ gfortran gcc-toolset-14-gcc-gfortran gdb gcc-toolset-14-gdb 4.8.2. Accessing and running the GCC Toolset container image The following section describes how to access and run the GCC Toolset container image. Prerequisites Podman is installed. Procedure Access the Red Hat Container Registry using your Customer Portal credentials: Pull the container image you require by running a relevant command as root: Replace toolset_version with the GCC Toolset version, for example 14 . Note On RHEL 8.1 and later versions, you can set up your system to work with containers as a non-root user. For details, see Setting up rootless containers . Optional: Check that pulling was successful by running a command that lists all container images on your local system: Run a container by launching a bash shell inside a container: The -i option creates an interactive session; without this option the shell opens and instantly exits. The -t option opens a terminal session; without this option you cannot type anything to the shell. Additional resources Building, running, and managing Linux containers on RHEL 8 Understanding root inside and outside a container (Red Hat Blog article) GCC Toolset container entries in the Red Hat Ecosystem Catalog 4.8.3. Example: Using the GCC Toolset 14 Toolchain container image This example shows how to pull and start using the GCC Toolset 14 Toolchain container image. Prerequisites Podman is installed. Procedure Access the Red Hat Container Registry using your Customer Portal credentials: Pull the container image as root: Launch the container image with an interactive shell as root: Run the GCC Toolset tools as expected. For example, to verify the gcc compiler version, run: To list all packages provided in the container, run: 4.9. Compiler toolsets RHEL 8 provides the following compiler toolsets as Application Streams: LLVM Toolset provides the LLVM compiler infrastructure framework, the Clang compiler for the C and C++ languages, the LLDB debugger, and related tools for code analysis. Rust Toolset provides the Rust programming language compiler rustc , the cargo build tool and dependency manager, the cargo-vendor plugin, and required libraries. Go Toolset provides the Go programming language tools and libraries. Go is alternatively known as golang . For more details and information about usage, see the compiler toolsets user guides on the Red Hat Developer Tools page. 4.10. The Annobin project The Annobin project is an implementation of the Watermark specification project. Watermark specification project intends to add markers to Executable and Linkable Format (ELF) objects to determine their properties. The Annobin project consists of the annobin plugin and the annockeck program. The annobin plugin scans the GNU Compiler Collection (GCC) command line, the compilation state, and the compilation process, and generates the ELF notes. The ELF notes record how the binary was built and provide information for the annocheck program to perform security hardening checks. The security hardening checker is part of the annocheck program and is enabled by default. It checks the binary files to determine whether the program was built with necessary security hardening options and compiled correctly. annocheck is able to recursively scan directories, archives, and RPM packages for ELF object files. Note The files must be in ELF format. annocheck does not handle any other binary file types. The following section describes how to: Use the annobin plugin Use the annocheck program Remove redundant annobin notes 4.10.1. Using the annobin plugin The following section describes how to: Enable the annobin plugin Pass options to the annobin plugin 4.10.1.1. Enabling the annobin plugin The following section describes how to enable the annobin plugin via gcc and via clang . Procedure To enable the annobin plugin with gcc , use: If gcc does not find the annobin plugin, use: Replace /path/to/directory/containing/annobin/ with the absolute path to the directory that contains annobin . To find the directory containing the annobin plugin, use: To enable the annobin plugin with clang , use: Replace /path/to/directory/containing/annobin/ with the absolute path to the directory that contains annobin . 4.10.1.2. Passing options to the annobin plugin The following section describes how to pass options to the annobin plugin via gcc and via clang . Procedure To pass options to the annobin plugin with gcc , use: Replace option with the annobin command line arguments and replace file-name with the name of the file. Example To display additional details about what annobin it is doing, use: Replace file-name with the name of the file. To pass options to the annobin plugin with clang , use: Replace option with the annobin command line arguments and replace /path/to/directory/containing/annobin/ with the absolute path to the directory containing annobin . Example To display additional details about what annobin it is doing, use: Replace file-name with the name of the file. 4.10.2. Using the annocheck program The following section describes how to use annocheck to examine: Files Directories RPM packages annocheck extra tools Note annocheck recursively scans directories, archives, and RPM packages for ELF object files. The files have to be in the ELF format. annocheck does not handle any other binary file types. 4.10.2.1. Using annocheck to examine files The following section describes how to examine ELF files using annocheck . Procedure To examine a file, use: Replace file-name with the name of a file. Note The files must be in ELF format. annocheck does not handle any other binary file types. annocheck processes static libraries that contain ELF object files. Additional information For more information about annocheck and possible command line options, see the annocheck man page on your system. 4.10.2.2. Using annocheck to examine directories The following section describes how to examine ELF files in a directory using annocheck . Procedure To scan a directory, use: Replace directory-name with the name of a directory. annocheck automatically examines the contents of the directory, its sub-directories, and any archives and RPM packages within the directory. Note annocheck only looks for ELF files. Other file types are ignored. Additional information For more information about annocheck and possible command line options, see the annocheck man page on your system. 4.10.2.3. Using annocheck to examine RPM packages The following section describes how to examine ELF files in an RPM package using annocheck . Procedure To scan an RPM package, use: Replace rpm-package-name with the name of an RPM package. annocheck recursively scans all the ELF files inside the RPM package. Note annocheck only looks for ELF files. Other file types are ignored. To scan an RPM package with provided debug info RPM, use: Replace rpm-package-name with the name of an RPM package, and debuginfo-rpm with the name of a debug info RPM associated with the binary RPM. Additional information For more information about annocheck and possible command line options, see the annocheck man page on your system. 4.10.2.4. Using annocheck extra tools annocheck includes multiple tools for examining binary files. You can enable these tools with the command-line options. The following section describes how to enable the: built-by tool notes tool section-size tool You can enable multiple tools at the same time. Note The hardening checker is enabled by default. 4.10.2.4.1. Enabling the built-by tool You can use the annocheck built-by tool to find the name of the compiler that built the binary file. Procedure To enable the built-by tool, use: Additional information For more information about the built-by tool, see the --help command-line option. 4.10.2.4.2. Enabling the notes tool You can use the annocheck notes tool to display the notes stored inside a binary file created by the annobin plugin. Procedure To enable the notes tool, use: The notes are displayed in a sequence sorted by the address range. Additional information For more information about the notes tool, see the --help command-line option. 4.10.2.4.3. Enabling the section-size tool You can use the annocheck section-size tool display the size of the named sections. Procedure To enable the section-size tool, use: Replace name with the name of the named section. The output is restricted to specific sections. A cumulative result is produced at the end. Additional information For more information about the section-size tool, see the --help command-line option. 4.10.2.4.4. Hardening checker basics The hardening checker is enabled by default. You can disable the hardening checker with the --disable-hardened command-line option. 4.10.2.4.4.1. Hardening checker options The annocheck program checks the following options: Lazy binding is disabled using the -z now linker option. The program does not have a stack in an executable region of memory. The relocations for the GOT table are set to read only. No program segment has all three of the read, write and execute permission bits set. There are no relocations against executable code. The runpath information for locating shared libraries at runtime includes only directories rooted at /usr. The program was compiled with annobin notes enabled. The program was compiled with the -fstack-protector-strong option enabled. The program was compiled with -D_FORTIFY_SOURCE=2 . The program was compiled with -D_GLIBCXX_ASSERTIONS . The program was compiled with -fexceptions enabled. The program was compiled with -fstack-clash-protection enabled. The program was compiled at -O2 or higher. The program does not have any relocations held in a writeable. Dynamic executables have a dynamic segment. Shared libraries were compiled with -fPIC or -fPIE . Dynamic executables were compiled with -fPIE and linked with -pie . If available, the -fcf-protection=full option was used. If available, the -mbranch-protection option was used. If available, the -mstackrealign option was used. 4.10.2.4.4.2. Disabling the hardening checker The following section describes how to disable the hardening checker. Procedure To scan the notes in a file without the hardening checker, use: Replace file-name with the name of a file. 4.10.3. Removing redundant annobin notes Using annobin increases the size of binaries. To reduce the size of the binaries compiled with annobin you can remove redundant annobin notes. To remove the redundant annobin notes use the objcopy program, which is a part of the binutils package. Procedure To remove the redundant annobin notes, use: Replace file-name with the name of the file. 4.10.4. Specifics of annobin in GCC Toolset 12 Under some circumstances, due to a synchronization issue between annobin and gcc in GCC Toolset 12, your compilation can fail with an error message that looks similar to the following: 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: aarch64 i686 ppc64le s390x x86_64

Commands:
yum install gcc-toolset- N
yum list available gcc-toolset- N -\*
yum install package_name
yum install gcc-toolset-13-annobin-annocheck gcc-toolset-13-binutils-devel
yum remove gcc-toolset- N \*
scl enable gcc-toolset- N tool
scl enable gcc-toolset- N bash
scl enable gcc-toolset-9 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-9 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-9 'ld -lsomelib objfile.o'
scl enable gcc-toolset-9 'ld objfile.o -lsomelib'
scl enable gcc-toolset-10 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-10 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-10 'ld -lsomelib objfile.o'
scl enable gcc-toolset-10 'ld objfile.o -lsomelib'
scl enable gcc-toolset-11 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-11 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-11 'ld -lsomelib objfile.o'
scl enable gcc-toolset-11 'ld objfile.o -lsomelib'
scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-12 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-12 'ld -lsomelib objfile.o'
scl enable gcc-toolset-12 'ld objfile.o -lsomelib'
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
cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/ architecture -linux-gnu/12/plugin ln -s annobin.so gcc-annobin.so
scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-13 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-13 'ld -lsomelib objfile.o'
scl enable gcc-toolset-13 'ld objfile.o -lsomelib'
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
cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/ architecture -linux-gnu/13/plugin ln -s annobin.so gcc-annobin.so
scl enable gcc-toolset-14 'gcc -lsomelib objfile.o'
scl enable gcc-toolset-14 'gcc objfile.o -lsomelib'
scl enable gcc-toolset-14 'ld -lsomelib objfile.o'
scl enable gcc-toolset-14 'ld objfile.o -lsomelib'
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
cd /opt/rh/gcc-toolset-14/root/usr/lib/gcc/ architecture -linux-gnu/14/plugin ln -s annobin.so gcc-annobin.so
podman login registry.redhat.io Username: username Password: ********
podman pull registry.redhat.io/rhel8/gcc-toolset- <toolset_version> -toolchain
podman images
podman run -it image_name /bin/bash
podman login registry.redhat.io Username: username Password: ********
podman pull registry.redhat.io/rhel8/gcc-toolset-14-toolchain
podman run -it registry.redhat.io/rhel8/gcc-toolset-14-toolchain /bin/bash
bash-4.4USD gcc -v gcc version 14.2.1 20240801 (Red Hat 14.2.1-1) (GCC)
bash-4.4USD rpm -qa
gcc -fplugin=annobin
gcc -iplugindir= /path/to/directory/containing/annobin/
gcc --print-file-name=plugin
clang -fplugin= /path/to/directory/containing/annobin/
gcc -fplugin=annobin -fplugin-arg-annobin- option file-name
gcc -fplugin=annobin -fplugin-arg-annobin-verbose file-name
clang -fplugin= /path/to/directory/containing/annobin/ -Xclang -plugin-arg-annobin -Xclang option file-name
clang -fplugin=/usr/lib64/clang/10/lib/annobin.so -Xclang -plugin-arg-annobin -Xclang verbose file-name
annocheck file-name
annocheck directory-name
annocheck rpm-package-name
annocheck rpm-package-name --debug-rpm debuginfo-rpm
annocheck --enable-built-by
annocheck --enable-notes
annocheck --section-size= name
annocheck --enable-notes --disable-hardened file-name
objcopy --merge-notes file-name
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
cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/ architecture -linux-gnu/12/plugin ln -s annobin.so gcc-annobin.so