Re: Linux ELF OS ABI

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Feb 19, 2010 at 6:27 AM, Doug Semler <dougsemler@gmail.com> wrote:
> 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

That is why I have been providing binutils binaries compiled on RHEL4.
It is getting harder and harder since gold needs g++ 4.2.

-- 
H.J.