Linux ELF OS ABI

[Doug Semler <dougsemler at gmail dot com>]

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.

What is weird is that if I link the shared object with --strip-all it
will not work.  If I then strip the shared object with strip, it is
loadable.  The only difference between the two shared object files is
the ELF OS ABI (byte 8), otherwise they are the same.

Is there a way to find out which symbol is causing this ABI to be
selected?  It looks like there is a function in elf.c that asks if
there are any symbols of type STT_GNU_IFUNC.  How can I find out what
symbols are of this type?

Additionally, I would have expected the output from strip to keep this
if it was necessary, which makes it seem as if there is something
funny going on in the linker...

It seems that what I do should be supported...even a simple program
that has the following seems that it should run on older systems, but
it doesn't.  Or am I completely whacked and have to keep an older
system around so that I can compile for that system (which seems
silly).

 shared.c  -  compile into shared library
 ----
 int foo()
 {
    return 42;
 }

 main.c - compile and link against shared library
 ----
 extern int foo();
 int main()
 {
    return foo();
 }