Re: adding rpath to existing executable

Re: adding rpath to existing executable

[Kasper Peeters]

>    Is there a simple way to add an RPATH to an already existing
>    executable using binutils?  (this is on i386 elf)
> 
> No.

Ok, let me ask this in a different way ;-)

Is there a _complicated_ way to add an RPATH to an already existing
executable using binutils? 

I looked at libbfd for half an hour, and it seems like I could just
read the executable file using bfd_openr and friends, add the rpath to
the private data and write it back. But I find it hard to believe that
nobody else has had a need for such a program before. 

Is libbfd capable of doing this or is more trickery involved that I am
not aware of?

Kasper

adding rpath to existing executable

[Kasper Peeters]

Is there a simple way to add an RPATH to an already existing
executable using binutils?  (this is on i386 elf)

Kasper

Re: adding rpath to existing executable

[Ian Lance Taylor]

   From: Kasper Peeters <K.Peeters@damtp.cam.ac.uk>
   Date: Sat, 19 Jun 1999 12:15:03 +0100 (BST)

   Is there a simple way to add an RPATH to an already existing
   executable using binutils?  (this is on i386 elf)

No.

Ian

Re: adding rpath to existing executable

[Richard Henderson]

On Sun, Jun 20, 1999 at 10:38:28PM +0100, Kasper Peeters wrote:
> Is there a _complicated_ way to add an RPATH to an already existing
> executable using binutils? 

I don't think so.

> But I find it hard to believe that
> nobody else has had a need for such a program before. 

I've seen such a program before, but it was written to directly
manipulate the ELF file structures.

> Is libbfd capable of doing this or is more trickery involved that I am
> not aware of?

There has to be room in one of the existing loadable segments
(usually at the end of the readonly segment containing .text),
and if there isn't, you have to add a new loadable segment
somewhere in the address space.  This can also mean shifting the
loadable segments around in the executable image to make room.

The general case is exceedingly ugly.


r~

Re: adding rpath to existing executable

[Ian Lance Taylor]

   From: Kasper Peeters <K.Peeters@damtp.cam.ac.uk>
   Date: Sun, 20 Jun 1999 22:38:28 +0100 (BST)

   >    Is there a simple way to add an RPATH to an already existing
   >    executable using binutils?  (this is on i386 elf)
   > 
   > No.

   Ok, let me ask this in a different way ;-)

   Is there a _complicated_ way to add an RPATH to an already existing
   executable using binutils? 

   I looked at libbfd for half an hour, and it seems like I could just
   read the executable file using bfd_openr and friends, add the rpath to
   the private data and write it back. But I find it hard to believe that
   nobody else has had a need for such a program before. 

You could do that, but it wouldn't work.  That is because RPATH goes
into a loadable segment.  When you changed the size of the RPATH, you
would be adjusting the position of everything else in that segment.
The program was linked to expect things to be at a certain position.
When you change that position, the program will no longer work.

   Is libbfd capable of doing this or is more trickery involved that I am
   not aware of?

libbfd is capable of changing the RPATH in certain circumstances which
Richard mentioned: when you can find some place to squeeze it in.  But
you have to do all the work yourself.

I've never known anybody to want to change the RPATH of a linked
executable.  Mostly, people just run a shell script which sets
LD_LIBRARY_PATH.  Otherwise, they rebuild the program, or in extreme
cases they hack the dynamic linker.

Ian

Re: adding rpath to existing executable

[Marty Leisner]

> 
> >    Is there a simple way to add an RPATH to an already existing
> >    executable using binutils?  (this is on i386 elf)
> > 
> > No.
> 
> Ok, let me ask this in a different way ;-)
> 
> Is there a _complicated_ way to add an RPATH to an already existing
> executable using binutils? 
> 
> I looked at libbfd for half an hour, and it seems like I could just
> read the executable file using bfd_openr and friends, add the rpath to
> the private data and write it back. But I find it hard to believe that
> nobody else has had a need for such a program before. 
> 
> Is libbfd capable of doing this or is more trickery involved that I am
> not aware of?
> 
> Kasper

I would find such a program to be very useful.  But I get around it
with aliases/shell scripts with play with LD_LIBRARY_PATH)

On another note, is there any documentation for how the dynamic linker for elf
works?

Reading rtld.c, there's:
Valid options for the LD_DEBUG environment variable are:\n\
\n\
  bindings  display information about symbol binding\n\
  files     display processing of files and libraries\n\
  help      display this help message and exit\n\
  libs      display library search paths\n\
  reloc     display relocation processing\n\
  symbols   display symbol table processing\n\
  versions  display version dependencies\n\
\n\

This seems very useful, it is documented anyplace?

Marty Leisner



-- 
marty
leisner@rochester.rr.com  
The Feynman problem solving Algorithm
        1) Write down the problem
        2) Think real hard
        3) Write down the answer
                Murray Gell-mann in the NY Times

Re: adding rpath to existing executable

[Kasper Peeters]

> I've never known anybody to want to change the RPATH of a linked
> executable.  Mostly, people just run a shell script which sets
> LD_LIBRARY_PATH.

I am on a system which has glibc-2.0, but I _need_ glibc-2.1 for my
own programs (because glibc-2.0 contains a fatal bug that my program
is triggering). If I set LD_LIBRARY_PATH to point to my glibc-2.1
directory, the glibc-2.0 dynamic linker prefers the glibc-2.1
libraries over the glibc-2.0 ones and (of course) fails. 

I don't want to wrap all of my stuff in scripts, and I can't really
either, since some of them are dynamically loaded modules themselves
while others call old glibc-2.0 ones. It's going to be a mess that
way.

> Otherwise, they rebuild the program, or in extreme
> cases they hack the dynamic linker.

I could modify the dynamic linker for glibc-2.1 to look at
LD_LIBRARY_PAT2 instead of LD_LIBRARY_PATH. Guess that's the easiest
way out.

Kasper