Chapter 2.  Red Hat Developer Toolset 9.0 Release

Dyninst 10 is provided only for the AMD64 and Intel 64 architectures.

Using C++ object files compiled with GCC versions earlier than 9.1.0 can cause ABI incompatibilities. When the C++ std::rotate algorithm is called with an empty range, the compiled program can terminate unexpectedly with a divide-by-zero error (as a SIGFPE signal). To work around this problem, recompile all objects that might call std::rotate with an empty range.

Executable files created with Red Hat Developer Toolset are dynamically linked in a nonstandard way. As a consequence, Fortran code cannot handle input/output (I/O) operations asynchronously even if this functionality is requested. To work around this problem, link the libgfortran library statically with the -static-libgfortran option to enable asynchronous I/O operations in Fortran code. Note that Red Hat discourages static linking for security reasons.

In Red Hat Developer Toolset, libraries are linked via 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 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, such as:

gcc -lsomelib objfile.o

Such use of a library from Red Hat Developer Toolset results in linker error messages undefined reference to symbol. To enable successful symbol resolution and linking, follow the standard linking practice and specify the option adding the library after the options specifying the object files:

gcc objfile.o -lsomelib

Note that this recommendation applies when using the version of GCC available as a part of Red Hat Enterprise Linux, too.

GCC in Red Hat Developer Toolset 3.x contained the libasan package, which might have conflicted with the system version of libasan. As a consequence, depending on which libasan was present in the system, the -fsanitize=address tool worked only either with the system GCC or with the Red Hat Developer Toolset version of GCC, but not with both at the same time. To prevent the described conflict, in Red Hat Developer Toolset 4.x and later versions, the package was renamed to libasanN, where N is a number. However, if the Red Hat Software Collections repository is enabled, the problem can occur after the system update because the system version of libasan is available in an earlier version than the Red Hat Developer Toolset 3.x version, which is still available in the repository. To work around this problem, exclude this package while updating:

~]$ yum update --exclude=libasan

When the user attempts to start the devtoolset-9-stap-server service, an SELinux AVC denial occurs on the IBM POWER, little endian architecture. To work around this problem, disable SELinux, start the service, and enable SELinux.

OProfile 1.3.0 and OProfile 1.2.0 shipped in Red Hat Developer Toolset works on all supported architectures, with the exception of IBM Z, where only the ocount tool works on the following models: z196, zEC12, and z13. operf and the other tools, such as oparchive or opannotate, do not work on IBM Z. For profiling purposes, users are recommended to use the Red Hat Enterprise Linux 7 system OProfile 0.9.9 version, which supports opcontrol with TIMER software interrupts.

Note that for correct reporting of data collected by OProfile 0.9.9, the corresponding opreport utility is necessary. Thus opcontrol-based profiling should be performed with Red Hat Developer Toolset disabled because the reporting tools from Red Hat Developer Toolset cannot process data collected within opcontrol legacy mode correctly.

The default Valgrind gdbserver support (--vgdb=yes) can cause certain register and flags values to be not always up-to-date due to optimizations done by the Valgrind core. The GDB utility is therefore unable to show certain parameters or variables of programs running under Valgrind. To work around this problem, use the --vgdb=full parameter. Note that programs might run slower under Valgrind when this parameter is used.

The devtoolset-version-package_name-debuginfo packages can conflict with the corresponding packages from the base Red Hat Enterprise Linux system or from other versions of Red Hat Developer Toolset. This namely applies to devtoolset-version-gcc-debuginfo, devtoolset-version-ltrace-debuginfo, devtoolset-version-valgrind-debuginfo, and might apply to other debuginfo packages, too. A similar conflict can also occur in a multilib environment, where 64-bit debuginfo packages conflict with 32-bit debuginfo packages.

For example, on Red Hat Enterprise Linux 7, devtoolset-7-gcc-debuginfo conflicts with three packages: gcc-base-debuginfo, gcc-debuginfo, and gcc-libraries-debuginfo. On Red Hat Enterprise Linux 6, devtoolset-7-gcc-debuginfo conflicts with one package: gcc-libraries-debuginfo. As a consequence, if conflicting debuginfo packages are installed, attempts to install Red Hat Developer Toolset can fail with a transaction check error message similar to the following examples:

file /usr/lib/debug/usr/lib64/libitm.so.1.0.0.debug from install of gcc-base-debuginfo-4.8.5-16.el7.x86_64 conflicts with file from package devtoolset-7-gcc-debuginfo-7.2.1-1.el7.x86_64

file /usr/lib/debug/usr/lib64/libtsan.so.0.0.0.debug from install of gcc-debuginfo-4.8.5-16.el7.x86_64 conflicts with file from package devtoolset-7-gcc-debuginfo-7.2.1-1.el7.x86_64

file /usr/lib/debug/usr/lib64/libitm.so.1.0.0.debug from install of devtoolset-7-gcc-debuginfo-7.2.1-1.el6.x86_64 conflicts with file from package gcc-libraries-debuginfo-7.1.1-2.3.1.el6_9.x86_64

To work around the problem, manually uninstall the conflicting debuginfo packages prior to installing Red Hat Developer Toolset 9.0. It is advisable to install only the relevant debuginfo packages when necessary and expect such problems to happen.