Re: touch and utimens troubles on new/old software combinations

[Mike Frysinger]

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.