Re: Linux ELF OS ABI

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Feb 19, 2010 at 09:27:11AM -0500, Doug Semler wrote:
> OK, then, what is the recommended method for this?  Are you saying we
> need to maintain build machines for each distro that our various
> clients use?  This is client driven distro support...we've tried to
> convince them to "upgrade" but they have their own levels of support
> for their clients. Maintaining multiple machines just for the build
> process of the same base OS is, quite frankly, disturbing to me.  Not
> quite apples to apples, but we don't have to do this on Windows -
> compiling binaries on Windows 7 will still work on Win2K machines, as
> long as you only use functions available on the lowest common
> denominator...And I understand that you can't expect to use a newer
> interface (say, for example, passing the O_CLOEXEC available in
> 2.6.23+ flag to open) on a kernel level 2.6.18.  But I don't think it
> is out of the realm of expectations to have it work otherwise.   I
> thought this was the whole point of having .so/symbol versioning.
> It's not like this is a new concept...remember the painful hell going
> from a.out to ELF, what was it, 15 years ago??

At least glibc provides (through symbol versioning) backwards compatibility
(and other libraries ought to as well, when they aren't changing SONAME).
Which means if you compile/link against older glibc, it will work well
against a newer one.  So, you want to compile/link against the oldest glibc
(and with oldest gcc and other parts of the toolchain) you want to support.
In Fedora/RHEL world you can use mock for that, other distros likely have
something similar and if they don't, just prepare such a chroot yourself.

> What you've just written could be read in such a way that I can't
> expect my binaries built on my (updated to kernel 2.6.32) Fedora 12
> box to even work on a non-updated Fedora 12 (which is at, I believe,
> kernel 2.6.31) box!

Running kernel version shouldn't matter, and e.g. glibc is never adding new
symbol versions on release branches (and similarly other forwards
incompatible toolchain changes aren't usually introduced in updates, only
in new releases).

	Jakub