Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

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++
Copia collegamento

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
Copia collegamento

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
Copia collegamento

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.

6.4. RHEL 10 uses IEEE binary128 for long double on POWER
Copia collegamento

On the POWER (ppc64le) architecture, the default representation of the long double type changes from the IBM-specific double-double format to the standard IEEE 754 binary128 format in RHEL 10. Both formats use 16 bytes, but their internal representations differ. The C and C++ core runtime libraries in RHEL 10 (glibc and libstdc++) support both formats. The rest of the system uses binary128 by default. If your applications use the long double type on POWER, you must recompile them on RHEL 10 to ensure correct behavior.

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima