Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 4. Additional toolsets for development

4.1. Using the GCC Toolset
Copier lien

4.1.1. What is the GCC Toolset
Copier lien

Red Hat Enterprise Linux 9 continues support for 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.

4.1.2. Installing the GCC Toolset
Copier lien

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.

Procedure

  • To install the GCC Toolset version N: 

    # dnf install gcc-toolset-N
    Copy to Clipboard Toggle word wrap

4.1.3. Installing individual packages from the GCC Toolset
Copier lien

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 dnf package management tool. Use selective installation to access packages not installed by default with the full toolset.

Procedure

  1. List the packages available in the GCC Toolset version N: 

    $ dnf list available gcc-toolset-N-\*
    Copy to Clipboard Toggle word wrap

  2. To install any of these packages: 

    # dnf install package_name
    Copy to Clipboard Toggle word wrap

    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: 

    # dnf install gcc-toolset-13-annobin-annocheck gcc-toolset-13-binutils-devel
    Copy to Clipboard Toggle word wrap

4.1.4. Uninstalling the GCC Toolset
Copier lien

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

Procedure

  • To uninstall the GCC Toolset version N: 

    # dnf remove gcc-toolset-N\*
    Copy to Clipboard Toggle word wrap

4.1.5. Accessing the GCC Toolset
Copier lien

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.

Procedure

  • To run a single tool from the GCC Toolset version N: 

    $ scl enable gcc-toolset-N tool
    Copy to Clipboard Toggle word wrap

    Replace tool with the command provided by the tool you want to run.

  • To run a shell session where tool versions from the GCC Toolset version N override system versions of these tools: 

    $ scl enable gcc-toolset-N bash
    Copy to Clipboard Toggle word wrap

4.2. GCC Toolset 12
Copier lien

Learn about information specific to the GCC Toolset version 12 and the tools contained in this version.

4.2.1. Tools and versions provided by the GCC Toolset 12
Copier lien

GCC Toolset 12 provides the following tools and versions:

Expand
Table 4.1. Tool versions in the GCC Toolset 12
NameVersionDescription

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.2.2. C++ compatibility in the GCC Toolset 12
Copier lien

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

Important

The compatibility information presented here apply only to the GCC from the GCC Toolset 12.

C++14

This language standard is available in the GCC Toolset 12.

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.

C++11

This language standard is available in the GCC Toolset 12.

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.

C++98
This language standard is available in the GCC Toolset 12. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from the GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8.
C++17

This language standard is available in the GCC Toolset 12.

This is the default language standard setting for the 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 appropriate flag have been built using GCC version 10 or later.

C++20 and C++23

This language standard is available in the 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 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.

4.2.3. Specifics of GCC in the GCC Toolset 12
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-12 'gcc -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.2.4. Specifics of binutils in the GCC Toolset 12
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-12 'ld -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.2.5. Specifics of annobin in the GCC Toolset 12
Copier lien

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
Copy to Clipboard Toggle word wrap

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

  1. Change to the plugin directory: 

    # cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
    Copy to Clipboard Toggle word wrap

  2. Create the symbolic link: 

    # ln -s annobin.so gcc-annobin.so
    Copy to Clipboard Toggle word wrap

Replace architecture with the architecture you use in your system:

  • aarch64
  • i686
  • ppc64le
  • s390x
  • x86_64

4.3. GCC Toolset 13
Copier lien

Learn about information specific to the GCC Toolset version 13 and the tools contained in this version.

4.3.1. Tools and versions provided by the GCC Toolset 13
Copier lien

GCC Toolset 13 provides the following tools and versions:

Expand
Table 4.2. Tool versions in the GCC Toolset 13
NameVersionDescription

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.3.2. C++ compatibility in the GCC Toolset 13
Copier lien

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

Important

The compatibility information presented here apply only to the GCC from the GCC Toolset 13.

C++14

This language standard is available in the GCC Toolset 13.

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.

C++11

This language standard is available in the GCC Toolset 13.

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.

C++98
This language standard is available in the GCC Toolset 13. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from the GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8.
C++17

This language standard is available in the GCC Toolset 13.

This is the default language standard setting for the 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 appropriate flag have been built using GCC version 10 or later.

C++20 and C++23

These language standards are available in the 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 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.

4.3.3. Specifics of GCC in the GCC Toolset 13
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-13 'gcc -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.3.4. Specifics of binutils in the GCC Toolset 13
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-13 'ld -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.3.5. Specifics of annobin in the GCC Toolset 13
Copier lien

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
Copy to Clipboard Toggle word wrap

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

  1. Change to the plugin directory: 

    # cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin
    Copy to Clipboard Toggle word wrap

  2. Create the symbolic link: 

    # ln -s annobin.so gcc-annobin.so
    Copy to Clipboard Toggle word wrap

Replace architecture with the architecture you use in your system:

  • aarch64
  • i686
  • ppc64le
  • s390x
  • x86_64

4.4. GCC Toolset 14
Copier lien

Learn about information specific to the GCC Toolset version 14 and the tools contained in this version.

4.4.1. Tools and versions provided by the GCC Toolset 14
Copier lien

GCC Toolset 14 provides the following tools and versions:

Expand
Table 4.3. Tool versions in the GCC Toolset 14
NameVersionDescription

GCC

14.2.1

A portable compiler suite with support for 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.

Note

In RHEL 9.5, the system GDB was rebased to version 14.2, and GDB is no longer included in the GCC Toolset.

4.4.2. C++ compatibility in the GCC Toolset 14
Copier lien

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

Important

The compatibility information presented here apply only to the GCC from the GCC Toolset 14.

C++14

This language standard is available in the GCC Toolset 14.

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.

C++11

This language standard is available in the GCC Toolset 14.

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.

C++98
This language standard is available in the GCC Toolset 14. Binaries, shared libraries and objects built using this standard can be freely mixed regardless of being built with GCC from the GCC Toolset, Red Hat Developer Toolset, and RHEL 5, 6, 7 and 8.
C++17

This language standard is available in the GCC Toolset 14.

This is the default language standard setting for the 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 appropriate flag have been built using GCC version 10 or later.

C++20 and C++23

These language standards are available in the 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 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.

4.4.3. Specifics of GCC in the GCC Toolset 14
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-14 'gcc -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.4.4. Specifics of binutils in the GCC Toolset 14
Copier lien

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.

Static linking of libraries

Certain more recent library features are statically linked into applications built with the 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 the 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 corresponding 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: 

$ scl enable gcc-toolset-14 'ld -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.4.5. Specifics of annobin in the GCC Toolset 14
Copier lien

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
Copy to Clipboard Toggle word wrap

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

  1. Change to the plugin directory: 

    # cd /opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin
    Copy to Clipboard Toggle word wrap

  2. Create the symbolic link: 

    # ln -s annobin.so gcc-annobin.so
    Copy to Clipboard Toggle word wrap

Replace architecture with the architecture you use in your system:

  • aarch64
  • i686
  • ppc64le
  • s390x
  • x86_64

4.5. GCC Toolset 15
Copier lien

GCC Toolset 15 in Red Hat Enterprise Linux offers updated compilers and debuggers for C, C++, and Fortran. It enables building, testing, and optimizing applications with current features while maintaining system stability and support.

4.5.1. GCC Toolset 15 tools and versions
Copier lien

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

Expand
Table 4.4. Tool versions in the GCC Toolset 15

Name

Version

Description

GCC

15.1.1

A portable compiler suite with support for C, C++, and Fortran.

GDB

16.3

A command-line debugger for programs written in C, C++, and Fortran.

binutils

2.44

A collection of binary tools and other utilities to inspect and manipulate object files and binaries.

annobin

12.93

A build security checking tool.

dwz

0.16

A tool to optimize DWARF debugging information contained in ELF shared libraries and ELF executables for size.

4.5.2. C++ compatibility in the GCC Toolset 15
Copier lien

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.

Important

This compatibility information applies only to GCC from the GCC Toolset 15.

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

C++98
This language standard is available in the GCC Toolset 15. Binaries, shared libraries, and objects built using this standard can be freely mixed regardless of being built with GCC from the GCC Toolset 15, Red Hat Developer Toolset, and RHEL 5, 6, 7, and 8.
C++11
This language standard is available in the GCC Toolset 15.
C++14

This language standard is available in the GCC Toolset 15.

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.

C++17

This language standard is available in the GCC Toolset 15.

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.

C++20 and C++23, and C++26

These language standards are available in the GCC Toolset 15 only as an experimental, unstable, and unsupported capabilities. Additionally, the compatibility of objects, binary files, and libraries built using these standards 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.

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.

4.5.3. Specifics of GCC in the GCC Toolset 15
Copier lien

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.

Static linking of libraries
Certain more recent library features are statically linked into applications built with the GCC Toolset 15 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 the GCC Toolset 15, 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 corresponding 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: 

$ scl enable gcc-toolset-15 'gcc -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.5.4. Specifics of binutils in the GCC Toolset 15
Copier lien

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.

Static linking of libraries
GCC Toolset 15 statically links newer library features into applications to ensure compatibility across multiple Red Hat Enterprise Linux versions. Statically linked code can introduce minor security risks, because security updates require applications to be rebuilt. If a security vulnerability is discovered, Red Hat will notify developers to rebuild affected applications through a security advisory.
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 the GCC Toolset 15, 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 corresponding 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: 

$ scl enable gcc-toolset-15 'ld -lsomelib objfile.o'
Copy to Clipboard Toggle word wrap

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'
Copy to Clipboard Toggle word wrap

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

4.5.5. Specifics of annobin in the GCC Toolset 15
Copier lien

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
Copy to Clipboard Toggle word wrap

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

  1. Change to the plugin directory: 

    $ cd /opt/rh/gcc-toolset-15/root/usr/lib/gcc/architecture-linux-gnu/15/plugin
    Copy to Clipboard Toggle word wrap

  2. Create the symbolic link: 

    $ ln -s annobin.so gcc-annobin.so
    Copy to Clipboard Toggle word wrap

Replace architecture with the architecture used on your system:

  • aarch64
  • i686
  • ppc64le
  • s390x
  • x86_64

4.6. Using the GCC Toolset container image
Copier lien

Only the two latest GCC Toolset container images are supported. Container images of earlier GCC Toolset versions are unsupported.

The GCC Toolset 13 and the 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 rhel9 base image and is available for all architectures supported by RHEL 9:

  • AMD and Intel 64-bit architectures
  • The 64-bit ARM architecture
  • IBM Power Systems, Little Endian
  • 64-bit IBM Z

4.6.1. GCC Toolset container image contents
Copier lien

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

The GCC Toolset 14 Toolchain contents

The rhel9/gcc-toolset-14-toolchain container image consists of the following components:

Expand
ComponentPackage

gcc

gcc-toolset-14-gcc

g++

gcc-toolset-14-gcc-c++

gfortran

gcc-toolset-14-gcc-gfortran

4.6.2. Accessing and running the GCC Toolset container image
Copier lien

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.

Prerequisites

  • Podman is installed.

Procedure

  1. Access the Red Hat Container Registry by using your Customer Portal credentials: 

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap 
    Username: username
Password: **
    Copy to Clipboard Toggle word wrap

  2. Pull the container image you require by running a relevant command as root: 

    # podman pull registry.redhat.io/rhel8/gcc-toolset-<toolset_version>-toolchain
    Copy to Clipboard Toggle word wrap

    Replace toolset_version with the GCC Toolset version, for example 14.

    Note

    You can also set up your system to work with containers as a non-root user. For details, see Setting up rootless containers.

  3. Optional: Check that pulling was successful by running a command that lists all container images on your local system: 

    # podman images
    Copy to Clipboard Toggle word wrap

  4. Run a container by launching a bash shell inside a container: 

    # podman run -it image_name /bin/bash
    Copy to Clipboard Toggle word wrap

    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.

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

Prerequisites

  • Podman is installed.

Procedure

  1. Access the Red Hat Container Registry by using your Customer Portal credentials: 

    $ podman login registry.redhat.io
    Copy to Clipboard Toggle word wrap 
    Username: username
Password: **
    Copy to Clipboard Toggle word wrap

  2. Pull the container image as root: 

    # podman pull registry.redhat.io/rhel{ProductNumber}/gcc-toolset-14-toolchain
    Copy to Clipboard Toggle word wrap

  3. Launch the container image with an interactive shell as root: 

    # podman run -it registry.redhat.io/rhel{ProductNumber}/gcc-toolset-14-toolchain /bin/bash
    Copy to Clipboard Toggle word wrap

  4. Run the GCC Toolset tools as expected. For example, to verify the gcc compiler version, run: 

    bash-4.4$ gcc -v
    Copy to Clipboard Toggle word wrap 
    ...
gcc version 14.2.1 20240801 (Red Hat 14.2.1-1) (GCC)
    Copy to Clipboard Toggle word wrap

  5. To list all packages provided in the container, run: 

    bash-4.4$ rpm -qa
    Copy to Clipboard Toggle word wrap

4.7. Compiler toolsets
Copier lien

RHEL 9 provides the following compiler toolsets as Application Streams. You can use these toolsets to build applications with different versions of languages and tools.

  • 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.8. The Annobin project
Copier lien

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

4.8.1. Using the annobin plugin
Copier lien

The following section describes how to:

  • Enable the annobin plugin
  • Pass options to the annobin plugin

4.8.1.1. Enabling the annobin plugin
Copier lien

To add build security notes to binaries, enable the annobin plug-in by using command-line options with gcc or clang utilities.

Procedure

  • To enable the annobin plugin with gcc, use: 

    $ gcc -fplugin=annobin
    Copy to Clipboard Toggle word wrap

    • If gcc does not find the annobin plugin, use: 

      $ gcc -iplugindir=/path/to/directory/containing/annobin/
      Copy to Clipboard Toggle word wrap

      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: 

      $ gcc --print-file-name=plugin
      Copy to Clipboard Toggle word wrap

  • To enable the annobin plugin with clang, use: 

    $ clang -fplugin=/path/to/directory/containing/annobin/
    Copy to Clipboard Toggle word wrap

    Replace /path/to/directory/containing/annobin/ with the absolute path to the directory that contains annobin.

  • Optional: To remove the redundant annobin notes, use the objcopy utility: 

    $ objcopy --merge-notes file-name
    Copy to Clipboard Toggle word wrap

4.8.1.2. Passing options to the annobin plugin
Copier lien

To pass options to the annobin plugin, use the appropriate command-line arguments with gcc or clang.

Procedure

  • To pass options to the annobin plugin with gcc, use: 

    $ gcc -fplugin=annobin -fplugin-arg-annobin-option file-name
    Copy to Clipboard Toggle word wrap

    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: 

      $ gcc -fplugin=annobin -fplugin-arg-annobin-verbose file-name
      Copy to Clipboard Toggle word wrap

      Replace file-name with the name of the file.

  • To pass options to the annobin plugin with clang, use: 

    $ clang -fplugin=/path/to/directory/containing/annobin/ -Xclang -plugin-arg-annobin -Xclang option file-name
    Copy to Clipboard Toggle word wrap

    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: 

      $ clang -fplugin=/usr/lib64/clang/10/lib/annobin.so -Xclang -plugin-arg-annobin -Xclang verbose file-name
      Copy to Clipboard Toggle word wrap

      Replace file-name with the name of the file.

4.8.2. Using the annocheck program
Copier lien

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.8.2.1. Using annocheck to examine files
Copier lien

To verify hardening options and build security notes of ELF files, examine the files by using the annocheck tool.

Procedure

  • To examine a file, use: 

    $ annocheck file-name
    Copy to Clipboard Toggle word wrap

    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 resources

  • For more information about annocheck and possible command line options, see the annocheck man page on your system.

4.8.2.2. Using annocheck to examine directories
Copier lien

To examine ELF files in a directory, use the annocheck tool, which recursively scans directories, subdirectories, and archives.

Procedure

  • To scan a directory, use: 

    $ annocheck directory-name
    Copy to Clipboard Toggle word wrap

    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 resources

  • For more information about annocheck and possible command line options, see the annocheck man page on your system.

4.8.2.3. Using annocheck to examine RPM packages
Copier lien

To examine ELF files in an RPM package, use the annocheck tool, which recursively scans all ELF files inside the package.

Procedure

  • To scan an RPM package, use: 

    $ annocheck rpm-package-name
    Copy to Clipboard Toggle word wrap

    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: 

    $ annocheck rpm-package-name --debug-rpm debuginfo-rpm
    Copy to Clipboard Toggle word wrap

    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 resources

  • For more information about annocheck and possible command line options, see the annocheck man page on your system.

4.8.2.4. Using annocheck extra tools
Copier lien

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.8.2.4.1. Enabling the built-by tool
Copier lien

To find the name of the compiler that built a specific binary file, you can use the annocheck built-by tool.

Procedure

  • To enable the built-by tool, use: 

    $ annocheck --enable-built-by
    Copy to Clipboard Toggle word wrap

Additional resources

  • For more information about the built-by tool, see the --help command-line option.
4.8.2.4.2. Enabling the notes tool
Copier lien

To display the notes stored inside a binary file created by the annobin plug-in, you can use the annocheck notes tool.

Procedure

  • To enable the notes tool, use: 

    $ annocheck --enable-notes
    Copy to Clipboard Toggle word wrap

    The notes are displayed in a sequence sorted by the address range.

Additional resources

  • For more information about the notes tool, see the --help command-line option.
4.8.2.4.3. Enabling the section-size tool
Copier lien

To display the size of named sections, you can use the annocheck section-size tool.

Procedure

  • To enable the section-size tool, use: 

    $ annocheck --section-size=name
    Copy to Clipboard Toggle word wrap

    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 resources

  • For more information about the section-size tool, see the --help command-line option.
4.8.2.4.4. Hardening checker basics
Copier lien

The hardening checker is enabled by default. You can disable the hardening checker with the --disable-hardened command-line option.

4.8.2.4.4.1. Hardening checker options
Copier lien

The annocheck tool verifies binaries for various hardening options, such as stack protection, PIC/PIE usage, and secure linker settings. The following options are checked:

  • 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.8.2.4.4.2. Disabling the hardening checker
Copier lien

To skip security checks during binary analysis, disable the hardening checker by using the annocheck utility.

Procedure

  • To scan the notes in a file without the hardening checker, use: 

    $ annocheck --enable-notes --disable-hardened file-name
    Copy to Clipboard Toggle word wrap

    Replace file-name with the name of a file.

4.8.3. Specifics of annobin in the GCC Toolset 12
Copier lien

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
Copy to Clipboard Toggle word wrap

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

  1. Change to the plugin directory: 

    # cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
    Copy to Clipboard Toggle word wrap

  2. Create the symbolic link: 

    # ln -s annobin.so gcc-annobin.so
    Copy to Clipboard Toggle word wrap

Replace architecture with the architecture you use in your system:

  • aarch64
  • i686
  • ppc64le
  • s390x
  • x86_64
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début