This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linux ELF OS ABI


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).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]