Chapter 6. Notable changes in RHEL 10


Red Hat Enterprise Linux 10 introduces important changes that affect C and C++ application development.

6.1. Compatibility breaking changes in C++

GNU Compiler Collection (GCC) 12 and later introduce compatibility-breaking changes for C++ code that depends on condition variables not being able to throw exceptions and for code that relies on deprecated standard library class templates.

std::condition_variable::wait is now a thread cancellation point
In GCC 11 and earlier, the std::condition_variable::wait function was noexcept, which made it incompatible with thread cancellation. As a result, if a call to pthread_cancel canceled a thread blocked in std::condition_variable::wait, the process would be terminated. In GCC 12 and later, std::condition_variable::wait can be canceled by calls to the pthread_cancel function, which unwinds the stack. If you have code that depends on wait never throwing an exception, review the code and take appropriate action.
Deprecated class templates

Certain class templates have been deprecated in new versions of C++ and produce warning diagnostics in GCC 12 and later.

  • The following class templates have been deprecated in C++11 and later:

    • std::unary_function
    • std::binary_function
  • The std::iterator class template has been deprecated in C++17 and later.

To prevent the warning diagnostics, you can take one of the following actions:

  • When you do not want to make other changes to the code, silence the warning diagnostics by using GCC’s diagnostic pragmas. For example:

    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored “-Wdeprecated-declarations"
    class Functor : public std::unary_function<int, int>
    { /* … */ };
    #pragma GCC diagnostic pop
  • When you want your code to be compatible with later versions of C++, replace these class templates in the code with nested typedefs. For example, you can replace a std::unary_function base class with result_type and argument_type typedefs:

    class Functor
    {
      using result_type = int;
      using argument_type = int;
      /* … */
    };

6.2. Compatibility breaking changes to glibc

Updates to the GNU C Library (glibc) include compatibility breaking changes to the dynamic linker search algorithm, which no longer checks certain subdirectories for shared objects. This release also removes the catchsegv script and the libSegFault.so shared object.

Changes to how the dynamic linker finds shared objects

The following list describes changes to the dynamic linker search algorithm:

  • The dynamic linker no longer loads shared objects from the tls subdirectories on the library search path or the subdirectory that corresponds to the AT_PLATFORM system name.
  • The dynamic linker no longer searches subdirectories named after the legacy AT_HWCAP search mechanism.

Port your applications to the glibc-hwcaps mechanism, which has been available since RHEL 8.4.

Removed catchsegv script and libSegFault.so shared object
The catchsegv script and associated libSegFault.so shared object have been removed. You can use an out-of-process alternative for intercepting coredumps and backtraces, such as systemd-coredump and coredumpctl.

6.3. C23 support in glibc

The GNU C Library (glibc) in Red Hat Enterprise Linux 10 includes support for C standard library facilities associated with the ISO C23 language standard.

Red Hat Enterprise Linux 10 includes GNU Compiler Collection (GCC) 14 as the default C and C++ compiler. To compile C application code as ISO C23 with GCC, use an option such as -std=c23. If you use another GCC release (for example, from a compiler toolset) or a different compiler, use the dialect option and documentation for that toolchain. C23 language support varies by compiler version.

The glibc interfaces available to your program depend on the library version in Red Hat Enterprise Linux 10 and on the language and feature selection you pass to the compiler.

For details about specific headers, types, and functions, see the upstream documentation.

On POWER (ppc64le), RHEL 10 changes the default long double representation from IBM double-double to IEEE 754 binary128. Both formats use 16 bytes but differ internally. glibc and libstdc++ support both formats. Recompile applications by using long double on POWER for correct behavior.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top