10

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!

Alexandr Zarubkin
  • 899
  • 1
  • 11
  • 26

1 Answers1

9

  1. 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).

  2. 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).

oakad
  • 6,945
  • 1
  • 22
  • 31
  • I see. So glibc on target should be not older than glibc we've linked with. But what about kernel? Which one is considered containing "newer kernel features", for example, for glibc 2.13 compiled against kernel 3.14? Kernel 2.6.38 since it was released after glibc 2.13, or 3.15 since it is newer than kernel we've compiled against? – Alexandr Zarubkin Nov 27 '14 at 21:09
  • You need to check the particular APIs you're using. For example, there's a well known incompatibility in `epoll_ctl`, whereupon kernels before 2.6.9 handled one of its arguments differently and this fact is reflected in the man page. For most programs there's nothing to worry about, as most of the Linux API was rather stable over the last 10 years (with a notable exception of udev and graphics related stuff). – oakad Nov 28 '14 at 09:31
  • Thanks, and another small clarification: what kernel features can I use with glibc 2.13? Does it depend on kernel headers version I build glibc with? – Alexandr Zarubkin Nov 28 '14 at 12:37
  • It does not work that way. Returning to the epoll example: man page says "Support was added to glibc in version 2.3.2". So, if you've got an older glibc it means that you're not going to get the necessary include files and library wrappers. Same goes for all other non-trivial stuff. – oakad Nov 28 '14 at 13:15
  • Thanks. So it actually makes no sense (but no harm either) to compile old glibc with new kernel headers, right? – Alexandr Zarubkin Nov 28 '14 at 14:23
  • It will make no difference. If the version mismatch is too large (like really old glibc with recent kernel) it may fail to compile, because some headers where moved around and rearranged. – oakad Nov 28 '14 at 16:00