On Monday 02 June 2008, Bob Proulx wrote: > Daniel Jacobowitz wrote: > > Bob Proulx wrote: > > > Most common systems only support backward compatibility. I have not > > > heard of a system which supported forward compatibility. > > > > > > In other words, compiling on a platform usually results in an > > > executable that only runs on that version or later of components of > > > the system and not usually older versions. That has always been true > > > of unix-like systems. Sometimes it happens to work anyway simply by > > > the happy chance that nothing in the call graph changed. But it isn't > > > generally possible when new interfaces are added to the system. > > > > FYI, this is not how glibc handles kernel headers, and that's worked > > fine for many years. You compile against the newest version you would > > like to take advantage of, and specify the oldest version to be > > supported separately. > > I don't understand and would appreciate clarification. Are you saying > that this is how glibc is compiled? Or are you saying this is how > programs are compiled against glibc?
it is how glibc gets compiled and works internally. > For example I compile hello.c into a hello program. How do I specify > an older version of libc that I want the program to use so that it can > run on older systems? If my hello.c program uses new interfaces > introduced in glibc X.Y how does this program function when linked > with a glibc prior to the introduction of the interface? you dont. you tell glibc the older version of the kernel that it needs to run on. the ABI presented by glibc is always the same. some functions may be ENOSYS stubs however if the kernel headers do not provide information about interfaces (such as the *at functions). for example, if __NR_utimensat is not defined in the kernel headers, glibc will simply create a stub utimensat() that sets errno to ENOSYS and return an error. if it is defined, glibc will attempt the syscall (which may still fail with ENOSYS according to the kernel). > I am really surprised that you tell me that this works with glibc (it > does not work on traditional Unix systems such as say HP-UX) and I am > very interested to know how this is accomplished with glibc. glibc has an "assume kernel version" internal structure. it keeps track of when certain features were added to the kernel. at build time, it'll compare the version specified at configure time and include support for everything newer. then at runtime, it will attempt the very latest function. if that fails with ENOSYS, it'll fall back to older and older functions. you can see this at play by running `file` on any ELF on a Linux system. that kernel version that comes up is the kernel version that the glibc it was built against, was built against ;). on a Gentoo system, most things will look something like: /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped so when i compiled bash, it compiled against a version of glibc that was configured to work on linux-2.6.9 and newer. -mike
signature.asc
Description: This is a digitally signed message part.
