Chapter 5. Supplementary topics
5.1. Compatibility-breaking changes in compilers and development tools
With this update, the librtkaio library has been removed. This library provided high-performance real-time asynchronous I/O access for some files, which was based on Linux kernel Asynchronous I/O support (KAIO).
As a result of the removal:
Applications using the
LD_PRELOADmethod to load librtkaio display a warning about a missing library, load the librt library instead and run correctly.
Applications using the
LD_LIBRARY_PATHmethod to load librtkaio load the librt library instead and run correctly, without any warning.
Applications using the
dlopen()system call to access librtkaio directly load the librt library instead.
Users of librtkaio have the following options:
- Use the fallback mechanism described above, without any changes to their applications.
- Change code of their applications to use the librt library, which offers a compatible POSIX-compliant API.
- Change code of their applications to use the libaio library, which offers a compatible API.
Both librt and libaio can provide comparable features and performance under specific conditions.
Note that the libaio package has Red Hat compatibility level of 2, while librtk and the removed librtkaio level 1.
For more details, see https://fedoraproject.org/wiki/Changes/GLIBC223_librtkaio_removal
Sun RPC and NIS interfaces removed from
glibc library no longer provides Sun RPC and NIS interfaces for new applications. These interfaces are now available only for running legacy applications. Developers must change their applications to use the
libtirpc library instead of Sun RPC and
libnsl2 instead of NIS. Applications can benefit from IPv6 support in the replacement libraries.
nosegneg libraries for 32-bit Xen have been removed
glibc i686 packages contained an alternative
glibc build, which avoided the use of the thread descriptor segment register with negative offsets (
nosegneg). This alternative build was only used in the 32-bit version of the Xen Project hypervisor without hardware virtualization support, as an optimization to reduce the cost of full paravirtualization. These alternative builds are no longer used and they have been removed.
make new operator
!= causes a different interpretation of certain existing makefile syntax
!= shell assignment operator has been added to GNU
make as an alternative to the
$(shell …) function to increase compatibility with BSD makefiles. As a consequence, variables with name ending in exclamation mark and immediately followed by assignment such as
variable!=value are now interpreted as the shell assignment. To restore the previous behavior, add a space after the exclamation mark, such as
For more details and differences between the operator and the function, see the GNU
Valgrind library for MPI debugging support removed
libmpiwrap.so wrapper library for Valgrind provided by the
valgrind-openmpi package has been removed. This library enabled Valgrind to debug programs using the Message Passing Interface (MPI). This library was specific to the Open MPI implementation version in previous versions of Red Hat Enterprise Linux.
libmpiwrap.so are encouraged to build their own version from upstream sources specific to their MPI implementation and version. Supply these custom-built libraries to Valgrind using the
Development headers and static libraries removed from
valgrind-devel sub-package used to include development files for developing custom valgrind tools. This update removes these files because they do not have a guaranteed API, have to be linked statically, and are unsupported. The
valgrind-devel package still does contain the development files for valgrind-aware programs and header files such as
memcheck.h, which are stable and well-supported.
5.2. Options for running a RHEL 6 or 7 application on RHEL 8
To run a Red Hat Enterprise Linux 6 or 7 application on Red Hat Enterprise Linux 8, a spectrum of options is available. A system administrator needs detailed guidance from the application developer. The following list outlines the options, considerations, and resources provided by Red Hat.
- Run the application in a virtual machine with a matching RHEL version guest OS
- Resource costs are high for this option, but the environment is a close match to the application’s requirements, and this approach does not require many additional considerations. This is the currently recommended option.
- Run the application in a container based on the respective RHEL version
- Resource costs are lower than in the previous cases, while configuration requirements are stricter. For details on the relationship between container hosts and guest user spaces, see the Red Hat Enterprise Linux Container Compatibility Matrix.
- Run the application natively on RHEL 8
This option offers the lowest resource costs, but also the most strict requirements. The application developer must determine a correct configuration of the RHEL 8 system. The following resources can help the developer in this task:
Note that this list is not a complete set of resources needed to determine application compatibility. These are only starting points with lists of known incompatible changes and Red Hat policies related to compatibility.
Additionally, the What is Kernel Application Binary Interface (kABI)? Knowledge Centered Support article contains information relevant to kernel and compatibility.