glibc's use of gnu_indirect_function feature - is it backwards compatible?

[Bryan Ischo]

Hi there.  I have a unique environment with a runtime ld.so that doesn't 
know anything about gnu indirect functions, but am trying to build a 
glibc version 2.13 to run on it.  A problem that I am having is that the 
resulting libc shared object library has an ABI type of "GNU/Linux" 
instead of SYSV.  My loader will not load such libaries, and so I've 
researched ways to demote this libc to SYSV.

I should mention that the runtime is an i686 system 
(i686-unknown-linux-gnu).

I believe I understand the cause of the libc's ABI being set to 
GNU/Linux - it's because it includes "gnu indirect functions" and those 
require the new ABI, so the linker emits it.

What I don't understand is whether or not these indirect functions are 
backwards compatible with old linkers.  If I just rewrite the ABI 
version on the library to SYSV, will my ld.so (version 2.2.5) be able to 
use it?  As an example, consider the strstr function.  glibc implements 
a bunch of special magic that creates a strstr_ifunc and then somehow 
rigs it up to be used as an indirect function in place of strstr 
(right?).  Does this magic include some kind of fallback implementation 
that older loaders see and understand that just goes straight to the old 
strstr implementation?

I've tried my hardest to disable gnu indirect functions but they seem 
deeply embedded in the toolchain (only gcc lets you turn them off, 
although that has little effect on glibc which uses them regardless of 
what the assember or compiler supports).  The fact that glibc emits them 
no matter what the assembler or compiler supports leads me to believe 
that what is being emitted by glibc is backwards compatible; otherwise, 
glibc would have a hidden dependency on the linker and loader versions 
that it doesn't explicitly state, and I doubt that the glibc developers 
would do something that insidious.

Just looking for confirmation that if I, say, patch my binutils to leave 
the ABI identification alone even if the object "has gnu symbols" (in 
binutils parliance), can I expect things to "just work"?

Thanks!
Bryan