views:

27

answers:

1

If I do the following command on my executable called "version", compiled on Fedora Core 11, I get this output

file version

version: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

What's the significance of the 2.6.18 number towards the end, and is it any use in distinguishing to customers which version of some software they should download ?

From what I've looked at so far, this number is definitely not

  1. The kernel version
  2. The libc version
  3. Anything to do with the lsb_release

I'd like to get some easy identifier to allow customers to know which binary release they should download, which they should ideally be able to identify by typing a command (like uname -a, although that obviously isn't the one in this case).

Thanks

+4  A: 

It's the kernel version of the machine the binary was compiled on. If you use precompiled binaries from your distribution, it's the kernel version of a machine of the distribution vendor, probably in its compile farm.

It's relevant e.g. when considering syscalls. Say your binary uses the syscall no. X and you use a kernel which does not support X yet or worse has assigned syscall no. X to a different syscall.

The vanilla Linux Kernel User API is stable. That means every syscall available in Linux version A is available in Linux version B if A <=B. But it may happen that some developer releases his/her own development version of Linux (something like linux-2.6.18-xy) and s/he implements a new syscall. If s/he now compiles a binary using that kernel version, the binary gets tagged with that version. So, you are later on able to know that it may or may not work.

Btw, /usr/include/asm/unistd_32.h contains syscall numbers, excerpt:

[...]
#define __NR_restart_syscall      0
#define __NR_exit         1
#define __NR_fork         2
#define __NR_read         3
#define __NR_write        4
#define __NR_open         5
[...]
Johannes Weiß
Thanks - so effectively, the minimum kernel version that has binary compatibility with the executable ? I discounted a kernel version initially as a user space program only "depends" (like ldd output) on libc.so, but I can see the link there.
Simon K
You could say so. The real truth is a bit more subtile: Not every kernel version brings new syscalls AND in normal programs you use syscall wrappers from libc. So the numbers are not hardcoded in the program itself but in libc. But IF a kernel invented a new syscall, your program depends on it, you can't execute that program on a older kernel...
Johannes Weiß
Yes - that's what I was thinking - as a userspace program, I don't care about the kernel - only libc. But of course, libc must care about the kernel, since it bridges user space with the kernel. So, really, the number is the kernel version that libc was compiled against, which comes from the vendor (Fedora in this case).Thanks for your time
Simon K