This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: glibc and $ORIGIN
On Tuesday 05 May 2009 18:21:57 Ryan Arnold wrote:
> On Tue, May 5, 2009 at 5:19 PM, Ryan Arnold wrote:
> > There are ways to get around this but they're not for the faint of
> > heart. The following wiki shows how one can tell the compiler that
> > the loader lives elsewhere:
> >
> > http://sources.redhat.com/glibc/wiki/Testing/Builds
> >
> > And one can debug using the following trick:
> >
> > http://sources.redhat.com/glibc/wiki/Debugging/Development_Debugging#head
> >-0f2b610260f23db5655a16e911aa7134c6bcc0ba
> >
> > Most people only use this for debugging GLIBC builds. I don't
> > recommend it for production environments unless the entire toolchain
> > is standalone.
> >
> > A better alternative is a chroot jail with GLIBC installed into the
> > chroot / directory.
>
> Oh, now I see you want no absolute paths.. That's not going to work.
> The ELF executable your run has the absolute loader path embedded in
> the ELF header in the INTERP section:
>
> http://sources.redhat.com/glibc/wiki/Tips_and_Tricks/Loader_Tips_and_Tricks
>
> As far as I know the kernel always loads this loader unless you invoke
> the target loader FIRST and direct the loader to load the application.
correct ... if the ELF has a PT_INTERP, the kernel will execute that. if it
doesnt, then it just uses the entry point of the static ELF (like the ldso
itself).
-mike