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

[Bryan Ischo]

On 08/16/11 06:07, Carlos O'Donell wrote:
> On 8/15/2011 8:10 PM, Bryan Ischo wrote:
>> Thank you for sticking with this topic and continuing to offer
>> advice.  You are absolutely right; I learned after thinking that I
>> had succeeded that any program that I attempted to run that was
>> linked with/against my new gcc/glibc/binutils toolchain required
>> using the dynamic loader built as part of that toolchain.
>>
>> As an alternative to requiring the upgrade of the loader to use the
>> new toolchain, I am exploring just statically linking the toolchain
>> so that running the toolchain does not require a new loader.  A side
>> benefit is that the toochain should be easily relocatable, if my
>> understanding of the search paths involved is correct.
>>
>> Of course anything built using the toolchain will require the new
>> loader but since the environment in which the cross-compiled programs
>> will be run is easily upgraded to the new loader, this should be
>> easy.
> I would personally avoid linking statically.
>
> Install the new libraries to /opt/sysroot/, and build your applications
> with -Wl,--dynamic-linker=/opt/sysroot/lib/ld.so.1 and the appropriate
> -Wl,-rpath=....

Thank you for the suggestion, and I appreciate the advice.  Just curious 
- what is the harm in static linking?  Larger memory footprint of the 
compiler, but I doubt that would even be noticed in this day and age of 
12 GB development systems ...

Thanks!
Bryan