Question

Answer

In order to build GLIBC it is necessary to use a set of kernel header files. The GLIBC supplied with Sourcery CodeBench is built against what is known as a sanitized set of kernel headers for a recent kernel version. These headers are said to be sanitized because they only describe the kernel/userspace interface rather than any internal details of the kernel. The contents of the sanitized headers, which are installed as part of the kernel build process, are also independent of the actual configuration of the kernel being built.

Using sanitized kernel headers from a recent kernel means that applications compiled against the Sourcery CodeBench GLIBC binary, possibly referencing the supplied set of sanitized kernel headers, are able to take advantage of features in kernel versions up to and including the recent version, but not features added in later versions. As a general rule, however, the kernel does not break backwards compatibility with GLIBC, so applications should still work successfully with later kernel versions. The kernel version used to generate the sanitized headers can be determined by reading the header file arm-none-linux-gnueabi/libc/usr/include/linux/version.h, located in the Sourcery CodeBench install directory.

The question now arises of how old a kernel may be to successfully run an application compiled against the Sourcery CodeBench GLIBC. The minimum possible kernel version for such applications is specified by the --enable-kernel option at GLIBC configure time. For the version of GLIBC supplied with Sourcery CodeBench this is set to 2.6.14; an application built against this library must be run on a system using a kernel version no lower than that. Attempts to run Sourcery CodeBench-compiled applications on kernels earlier than 2.6.14 result in a "FATAL: kernel too old" error message before the application's main function is called.

Recall however that the GLIBC library knows about kernel features provided by kernels up to and including the recent kernel headers used to build GLIBC. In the event of the library determining at runtime that the system kernel does not support a particular feature, in almost all cases it uses fallback code instead. For the vast majority of applications this does not pose any problem and the behaviour of the program is unaffected. However applications that depend specifically on the use of GLIBC wrappers around system calls that are not present in the earlier version of the kernel being used may not work as expected. Such applications should therefore be run on a kernel that supports those system calls. It should be noted that the lack of kernel support for the call in this scenario manifests itself by the wrapper returning ENOSYS as an error number, rather than in a crash.

Sourcery CodeBench for ARM targets has a further kernel version constraint. The compilers in this toolchain emit objects that conform to the ARM EABI, which requires kernel support. Additionally, the GLIBC library requires certain NPTL kernel support. Kernel version 2.6.16 was the first release to contain all of this functionality. Thus it is safest for applications compiled with Sourcery CodeBench for ARM to be executed on systems running kernels of version 2.6.16 or higher. If applications must be run on kernels earlier than 2.6.16 but no older than 2.6.14 it is necessary that the kernel be patched for correct operation. At least the following EABI and NPTL patches (archived at http://www.arm.linux.org.uk/developer/patches/section.php?section=0) should be applied: 3101/1, 3102/1, 3103/1, 3104/1, 3105/4, 3106/2, 3107/3, 3108/2, 3109/1, 3110/2, 3111/2, 3112/1, 3205/1, 3210/1, 3270/1, 3271/1, 3339/1, 3477/1, 3484/1, 3495/1, 3524/1, 3626/1, 3729/3, 3750/3.

In summary:

• It is recommended to use at least a 2.6.16 ARM Linux kernel for applications compiled with Sourcery CodeBench.
• Kernels earlier than 2.6.16, but no older than 2.6.14, may also be used subject to the above patches being applied.
• These minimum kernel requirements allow the vast majority of applications to work as intended. If your application depends on newer kernel features, it is recommended that you check for and handle ENOSYS errors.
• Upgrading to later kernel versions does not necessitate recompilation of either GLIBC or the application.