This is the mail archive of the libc-help@sourceware.org mailing list for the glibc 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: glibc's use of gnu_indirect_function feature - is it backwardscompatible?


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


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