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 GCC Toolset
Copier lien

4.1.1. What is GCC Toolset
Copier lien

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
Copier lien

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: 

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

4.1.3. Installing individual packages from GCC Toolset
Copier lien

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

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

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

  2. To install any of these packages: 

    # yum 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: 

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

4.1.4. Uninstalling GCC Toolset
Copier lien

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

Procedure

  • To uninstall GCC Toolset version N: 

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

4.1.5. Running a tool from GCC Toolset
Copier lien

To run a tool from GCC Toolset, use the scl utility.

Procedure

  • To run a tool from GCC Toolset version N: 

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

4.1.6. Running a shell session with GCC Toolset
Copier lien

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: 

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

4.2. GCC Toolset 9
Copier lien

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
Copier lien

GCC Toolset 9 provides the following tools and versions:

Expand
Table 4.1. Tool versions in GCC Toolset 9
NameVersionDescription

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
Copier lien

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
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-9 '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 GCC Toolset 9
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-9 '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. GCC Toolset 10
Copier lien

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
Copier lien

GCC Toolset 10 provides the following tools and versions:

Expand
Table 4.2. Tool versions in GCC Toolset 10
NameVersionDescription

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
Copier lien

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
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-10 '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 GCC Toolset 10
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-10 '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. GCC Toolset 11
Copier lien

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
Copier lien

GCC Toolset 11 provides the following tools and versions:

Expand
Table 4.3. Tool versions in GCC Toolset 11
NameVersionDescription

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
Copier lien

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
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-11 '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 GCC Toolset 11
Copier lien

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: 

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

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: 

$ scl enable gcc-toolset-11 '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. GCC Toolset 12
Copier lien

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
Copier lien

GCC Toolset 12 provides the following tools and versions:

Expand
Table 4.4. Tool versions in 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.5.2. C++ compatibility in GCC Toolset 12
Copier lien

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
Copier lien

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: 

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

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: 

$ 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.5.4. Specifics of binutils in GCC Toolset 12
Copier lien

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: 

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

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: 

$ 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.5.5. Specifics of annobin in GCC Toolset 12
Copier lien

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: 

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: 

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# 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.6. GCC Toolset 13
Copier lien

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
Copier lien

GCC Toolset 13 provides the following tools and versions:

Expand
Table 4.5. Tool versions in 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.6.2. C++ compatibility in GCC Toolset 13
Copier lien

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
Copier lien

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: 

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

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: 

$ 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.6.4. Specifics of binutils in GCC Toolset 13
Copier lien

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: 

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

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: 

$ 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.6.5. Specifics of annobin in GCC Toolset 13
Copier lien

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: 

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: 

# cd /opt/rh/gcc-toolset-13/root/usr/lib/gcc/architecture-linux-gnu/13/plugin
# 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.7. GCC Toolset 14
Copier lien

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
Copier lien

GCC Toolset 14 provides the following tools and versions:

Expand
Table 4.6. Tool versions in GCC Toolset 14
NameVersionDescription

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
Copier lien

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
Copier lien

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: 

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

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: 

$ 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.7.4. Specifics of binutils in GCC Toolset 14
Copier lien

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: 

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

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: 

$ 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.7.5. Specifics of annobin in GCC Toolset 14
Copier lien

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: 

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: 

# cd /opt/rh/gcc-toolset-14/root/usr/lib/gcc/architecture-linux-gnu/14/plugin
# 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.8. 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.8.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 RHEL.

Expand
Table 4.7. Tool versions in 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.8.2. C++ compatibility in GCC Toolset 15
Copier lien

GCC Toolset 15 supports a range of C++ language standards. The default standard is C++17, but you can choose other options such as C++98, C++11, C++14, or experimental versions including C++20, C++23, and C++26. To select a different standard, use the appropriate compiler flag when building your code.

Important

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

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

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

This language standard is available in GCC Toolset 15.

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++17

This language standard is available in GCC Toolset 15.

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

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

These language standards are available in 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 GCC Toolset 15 for linking when you combine objects built with GCC Toolset 15 and objects built with the system toolchain, particulary .o or .a files. This ensures any newer library features provided only by GCC Toolset 15 are resolved at link time.

4.8.3. Specifics of GCC in GCC Toolset 15
Copier lien

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

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

Using a library from 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.8.4. Specifics of binutils in GCC Toolset 15
Copier lien

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 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 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: 

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

Using a library from 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.8.5. Specifics of annobin in GCC Toolset 15
Copier lien

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

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: 

$ cd /opt/rh/gcc-toolset-15/root/usr/lib/gcc/architecture-linux-gnu/15/plugin
$ 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.9. 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 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.9.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 rhel8/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

gdb

gcc-toolset-14-gdb

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

The following section describes how to access and run the GCC Toolset container image.

Prerequisites

  • Podman is installed.

Procedure

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

    $ podman login registry.redhat.io
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

    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.

  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.

This example shows how to pull and start using the GCC Toolset 14 Toolchain container image.

Prerequisites

  • Podman is installed.

Procedure

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

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

  2. Pull the container image as root: 

    # podman pull registry.redhat.io/rhel8/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/rhel8/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
...
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.10. Compiler toolsets
Copier lien

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.11. 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
  • Remove redundant annobin notes

4.11.1. Using the annobin plugin
Copier lien

The following section describes how to:

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

4.11.1.1. Enabling the annobin plugin
Copier lien

The following section describes how to enable the annobin plugin via gcc and via clang.

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.

4.11.1.2. Passing options to the annobin plugin
Copier lien

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: 

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

The following section describes how to examine ELF files using annocheck.

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.11.2.2. Using annocheck to examine directories
Copier lien

The following section describes how to examine ELF files in a directory using annocheck.

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.11.2.3. Using annocheck to examine RPM packages
Copier lien

The following section describes how to examine ELF files in an RPM package using annocheck.

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

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: 

    $ 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.11.2.4.2. Enabling the notes tool
Copier lien

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: 

    $ 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.11.2.4.3. Enabling the section-size tool
Copier lien

You can use the annocheck section-size tool display the size of the named sections.

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.11.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.11.2.4.4.1. Hardening checker options
Copier lien

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

The following section describes how to disable the hardening checker.

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.11.3. Removing redundant annobin notes
Copier lien

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: 

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

    Replace file-name with the name of the file.

4.11.4. Specifics of annobin in GCC Toolset 12
Copier lien

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: 

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: 

# cd /opt/rh/gcc-toolset-12/root/usr/lib/gcc/architecture-linux-gnu/12/plugin
# 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
Retour au début
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

© 2025 Red Hat