Chapter 2. Libraries and Runtime Support
Red Hat Enterprise Linux 6 supports the development of custom applications in a wide variety of programming languages using proven, industrial-strength tools. This chapter describes the runtime support libraries provided in Red Hat Enterprise Linux 6.
2.1. Compatibility
Compatibility specifies the portability of binary objects and source code across different instances of a computer operating environment. Officially, Red Hat supports current release and two consecutive prior versions. This means that applications built on Red Hat Enterprise Linux 4 and Red Hat Enterprise Linux 5 will continue to run on Red Hat Enterprise Linux 6 as long as they comply with Red Hat guidelines (using the symbols that have been white-listed, for example).
Red Hat understands that as an enterprise platform, customers rely on long-term deployment of their applications. For this reason, applications built against C/C++ libraries with the help of compatibility libraries continue to be supported for ten years.
There are two types of compatibility:
- Source Compatibility
- Source compatibility specifies that code will compile and execute in a consistent and predictable way across different instances of the operating environment. This type of compatibility is defined by conformance with specified Application Programming Interfaces (APIs).
- Binary Compatibility
- Binary Compatibility specifies that compiled binaries in the form of executables and Dynamic Shared Objects (DSOs) will run correctly across different instances of the operating environment. This type of compatibility is defined by conformance with specified Application Binary Interfaces (ABIs).
Note
Compilation of code using -devel packages from the Optional channel is not supported by Red Hat because libraries in the Optional channel are only provided for internal use by the operating system. They are not intended for general application development.
Among other things, this means that security issues in these libraries are only addressed if base operating system components provided by Red Hat are affected. It also means that you may not be able to easily determine whether the built application only uses libraries supported for use by non-Red Hat applications. Therefore, it is recommended to build software on systems that do not have packages from Optional channels installed.
For further information regarding this and all levels of compatibility between core and non-core libraries, see Red Hat Enterprise Linux Life Cycle and the general Red Hat Enterprise Linux Application Compatibility Policies.
2.1.1. Static Linking
Static linking is emphatically discouraged for all Red Hat Enterprise Linux releases. Static linking causes far more problems than it solves, and should be avoided at all costs.
The main drawback of static linking is that it is only guaranteed to work on the system on which it was built, and even then only until the next release of glibc or libstdc++ (in the case of C++). There is no forward or backward compatibility with a static build. Furthermore, any security fixes (or general-purpose fixes) in subsequent updates to the libraries will not be available unless the affected statically linked executables are re-linked.
A few more reasons why static linking should be avoided are:
- Larger memory footprint.
- Slower application startup time.
- Reduced glibc features with static linking.
- Security measures like load address randomization cannot be used.
- Dynamic loading of shared objects outside of glibc is not supported.
Note
The compat-glibc package is included with Red Hat Enterprise Linux 6, but it is not a runtime package and therefore not required for running anything. It is solely a development package, containing header files and dummy libraries for linking. This allows compiling and linking packages to run in older Red Hat Enterprise Linux versions (using compat-gcc-* against those headers and libraries). Running
rpm -qpi compat-glibc-* will provide some information on how to use this package.
