Jim Meyering wrote: > Mike Frysinger wrote: > > for example, if you're running a recent version of glibc (say 2.7) > > compiled against recent kernel headers (say 2.6.25) but execute on > > an older kernel (say 2.6.18), then the resulting touch binary will > > attempt to use utimensat() which fails with ENOSYS.
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. I think if you have received a bug report with this situation that you would have to answer that it isn't a supported configuration and it also isn't a supportable configuration. > I'm afraid the best advice I can give you is to run the tools on the same > (or newer) version of the system on which you configured the package. For binding against a previous library the standard technique is to build in a chroot using the older libraries. Then the resulting binary can run on systems with that library or newer. The library will maintain backward compatibility on newer systems. But of course it is the same kernel within the chroot as without and so doesn't help for changed system calls. Fortunately the kernel difference is usually hidden behind the library interface since programs don't usually make system calls directly, that is the task of the library, and so isn't as widespread of a problem. Bob
