Re: Linux ELF OS ABI

[Doug Semler <dougsemler at gmail dot com>]

On Fri, Feb 19, 2010 at 4:13 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Feb 18, 2010 at 09:13:10PM -0800, H.J. Lu wrote:
>> On Thu, Feb 18, 2010 at 1:57 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Thu, Feb 18, 2010 at 1:43 PM, Doug Semler <dougsemler@gmail.com> wrote:
>> >> I have a shared object that I compile on one machine (Fedora 12) and
>> >> run on another (CentOS5 or Ubuntu 8.04) machine. ?Things were fine
>> >> (ensuring that we only used older APIs) running this way until
>> >> recently. ?Recent compiles on the Fedora 12 machine started tagging
>> >> the shared libraries being built with the GNU/Linux ABI rather than
>> >> the Unknown (SYSV) ABI. ?The problem seems to be that on the older
>> >> machines, the shared object loader can't parse this (i get an ELF file
>> >> OS ABI invalid shared object when trying to load the .so file from an
>> >> executable). ?An executable tagged with the GNU/Linux ABI type runs
>> >> perfectly fine. ?I *think* the problems started when I updated the
>> >> glibc to 2.11.2 on the Fedora system.
> ...
>> It has been fixed:
>>
>> http://sourceware.org/ml/binutils-cvs/2010-02/msg00138.html
>>
>> You may want to open a Fedora bug to request backporting this fix.
>
> That said, expecting forwards compatibility (compiling/linking on a newer
> system, expecting it to work on older ones) is foolish, if it works, it is
> purely by accident and there have been many examples in the history where it
> didn't work for a big amount of binaries/libraries, eventhough the library
> SONAMEs didn't change. ?Examples are when a new symbol version for some
> widely used symbol is introduced (e.g. regexec in glibc 2.3.4) or a new
> function is fortified with -D_FORTIFY_SOURCE{,=2} (e.g. some symbols in
> glibc 2.8, or 2.7), or when DT_GNU_HASH has been introduced and on certain
> distros gcc was configured to default to just using this new hash and not
> the old one. ?Not sure how well old dynamic linkers will handle
> STB_GNU_UNIQUE symbols and not speaking at all about debug info (old
> toolchain just won't handle new DWARF 4 additions, or even many DWARF 3
> features that GCC started to use only in the 4.5 version (and has been
> backported to 4.4-RH).
>

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??

Honestly, the ideal situation would be to use the same toolchain
versions across the board (for linux and also a mingw cross).   The
only external library we link against that is distribution provided
*is* the glibc set, and that of the compiler.  Any other third party
code that we use is code compiled into a separate shared object
ourselves (LGPL code, etc) so that we can comply with the LGPL
licensing and so that we have the same known version across all
distros. That's why I found this to be so surprising, we are (well
apparently only "were") very careful to use functions that were only
provided by "the lowest common denominator."  Finding this was really
by accident, due to the fact that I updated my desktop machine to use
a newer glibc which had ifuncs.  But unfortunately we need to support
multiple older distributions.    What you also seem to be implying is
that we'd have to also build and maintain a toolchain for each build
machine as well (especially if we want to use, for example, the gcc
4.5 toolchain, or say, grab the binutils source and get this bugfix).

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!