Chapter 13. GCC Toolset 9

This chapter provides information specific to GCC Toolset version 9 and the tools contained in this version.

13.1. Tools and versions provided by GCC Toolset 9

GCC Toolset 9 provides the following tools and versions:

Table 13.1. Tool versions in GCC Toolset 9

NameVersionDescription

GCC

9.1.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

8.79

A build security checking tool.

13.2. C++ compatibility in GCC toolset 9

Important

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

The GCC compiler in the 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.

13.3. Specifics of GCC in GCC Toolset 9

Static linking of libraries

Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk as 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'

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

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

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

13.4. Specifics of binutils in GCC Toolset 9

Static linking of libraries

Certain more recent library features are statically linked into applications built with GCC Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This creates an additional minor security risk as 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'

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'

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