When building a compiler, one must specify Linux headers version and minumum supported kernel version, in addition to glibc version. And then there is actual kernel version and glibc version (with its own kernel headers version and minumum supported kernel version) on the target machine. I'm rather confused trying to understand how these versions go together.
Example 1: Assume I have system with glibc 2.13 built against kernel headers 3.14. Does that make any sense? How is it possible for glibc 2.13 (released in 2011) to use new kernel features from 3.14 (released in 2014)?
Example 2: Assume I have a compiler with glibc version newer than 2.13. Will compiled programs work on system with glibc 2.13? And if compiler's glibc version is older than 2.13?
Example 3: From https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F I understand that it's OK to use older kernel if it satisfies "minumum kernel version" used when compiling glibc. But I don't understand the passage The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected. For example you can't use new kernel features if you used old kernel headers to compile the GNU C library.. Is it the only thing that can happen to me? Won't it break something in glibc if the kernel is newer than at compile-time?
Example 4: Do more subtle differences in glibc settings (for example, linking an executable against glibc version 2.X compiled against kernel headers 3.Y with minimum supported kernel version 2.6.A and executing in on system with the same glibc 2.X, but compiled against kernel headers 3.Z with minumum supported kernel version 2.6.B) influence anything? I suspect they're not, but would like to be sure.
So many questions :) Thanks!
You can not easily (for whatever definition of the word) use newer kernel features with older versions of glibc. If you really need to, you can invoke system calls directly (using the syscall() library function) and dig whatever constant values and datastructures necessary from user-space kernel headers (the stuff which in the newer kernel is held under include/uapi). On the other hand, kernel developers usually promise not to break legacy features in newer kernels, so older glibc versions keep working as expected (well, almost).
Older programs still work with newer versions of glibc because glibc supports versioning of symbols (see here for some details: https://www.kernel.org/pub/software/libs/glibc/hjl/compat/). If your program is dynamically linked with newer version of glibc without special provisions (as described in the link above) you would not be able to run it with an older version of glibc libraries (dynamic linker will complain about unresolved symbols, as proper symbol versions will not be available).