Chapter 5. Supplementary topics 5.1. Compatibility-breaking changes in compilers and development tools librtkaio removed 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_PRELOAD method to load librtkaio display a warning about a missing library, load the librt library instead and run correctly. Applications using the LD_LIBRARY_PATH method 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 The 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. The nosegneg libraries for 32-bit Xen have been removed Previously, the 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 The != shell assignment operator has been added to GNU make as an alternative to the USD(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 behavior, add a space after the exclamation mark, such as variable! =value . For more details and differences between the operator and the function, see the GNU make manual. Valgrind library for MPI debugging support removed The 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 versions of Red Hat Enterprise Linux. Users of 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 LD_PRELOAD technique. Development headers and static libraries removed from valgrind-devel Previously, the 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 valgrind.h , callgrind.h , drd.h , helgrind.h , and 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 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: Red Hat Enterprise Linux 8: Application Compatibility Guide Red Hat Enterprise Linux 7: Application Compatibility Guide Release notes for Red Hat Enterprise Linux 8.0 Considerations in adopting RHEL 8 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. For more information about kernel and compatibility, see the Red Hat Knowledgebase solution What is Kernel Application Binary Interface (kABI)? .

Commands: