Very Computer

Suppose I have an executable binary (but not its source code)
which requires linking with one or more shared libraries at run time.

Is there a hack whereby I can merge the binary with the required
shared libraries and create a statically linked executable?

The reason for the asking is that I want to transport a program
from one Linux machine to another, where the target machine is
missing some of the required run time shared libraries and I don't
want to install the missing libraries there.

Weird question, I know, but it seems that it shouldn't be impossible.

--

 > Is there a hack whereby I can merge the binary with the required
 > shared libraries and create a statically linked executable?

Not with ready-made, pre-packaged tools.

 >
 > The reason for the asking is that I want to transport a program
 > from one Linux machine to another, where the target machine is
 > missing some of the required run time shared libraries and I don't
 > want to install the missing libraries there.

By creating a wrapper script for the application, and setting the
shell environment variable LD_LIBRARY_PATH in the script before
invoking the application, you can put the libraries anywhere
that you have access permission.  That still requires space and
presence, but it evades the requirement for residence in a fixed
place.

 > ... it seems that it shouldn't be impossible.

It's not impossible, just rare enough that no one previously has put together
the chain of tools, scripts, and new utilities to do it.

Quote:> > Is there a hack whereby I can merge the binary with the required
> > shared libraries and create a statically linked executable?

>Not with ready-made, pre-packaged tools.

> > The reason for the asking is that I want to transport a program
> > from one Linux machine to another, where the target machine is
> > missing some of the required run time shared libraries and I don't
> > want to install the missing libraries there.

>By creating a wrapper script for the application, and setting the
>shell environment variable LD_LIBRARY_PATH in the script before
>invoking the application, you can put the libraries anywhere
>that you have access permission.  That still requires space and
>presence, but it evades the requirement for residence in a fixed
>place.

Thanks for your comments.

I should have been more explicit in my message.  The missing
libraries are those of the old libc5.  In addition to the lib*.so
files, apparently I need libc5's dynamic loader, /lib/ld.so, which
is also missing on the target system.  Putting a copy of ld.so in
the LD_LIBRARY_PATH does not help.  I think ld.so is invoked first,
which looks up LD_LIBRARY_PATH, which is then used to find the rest
of the required *.so files.

I'd appreciate any additional suggestions.

--

Yes, there is a hack:
http://www.team-teso.net/releases/reducebind.c

You may also want to read this thread:
http://www.google.com/groups?selm=pan.2003.01.26.17.53.22.561790%40cs...

Cheeers,
--
In order to understand recursion you must first understand recursion.

    This is a very ugly^M^M^M^Mcool program. It starts the target executable
in traced mode, waits for it to long to all the dynamic libraries it wants,
and then writes out a snapshot of the image in executable form.

    DS

Rouben Rostamian enlightened us with:

Quote:> I'd appreciate any additional suggestions.

Suggestion: DO NOT put your real email address in your signature, unless
you want to receive A LOT more spam.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?

 > The missing
 > libraries are those of the old libc5.  In addition to the lib*.so
 > files, apparently I need libc5's dynamic loader, /lib/ld.so, which
 > is also missing on the target system.

"readelf --program-headers ./my_app" reveals the PT_INTERP segment,
which contains a string constant.  Use a binary file editor to overwrite
that string.  "/lib/ld.so" is rather short, but you could try
"/tmp/ld.so", or a symbolic link to somewhere from a 5-character
non-ASCII filename residing in /tmp, etc.

Quote:> > The missing
> > libraries are those of the old libc5.  In addition to the lib*.so
> > files, apparently I need libc5's dynamic loader, /lib/ld.so, which
> > is also missing on the target system.

>"readelf --program-headers ./my_app" reveals the PT_INTERP segment,
>which contains a string constant.  Use a binary file editor to overwrite
>that string.  "/lib/ld.so" is rather short, but you could try
>"/tmp/ld.so", or a symbolic link to somewhere from a 5-character
>non-ASCII filename residing in /tmp, etc.

That was a terrific idea.  I did what you suggested and everything
worked just perfectly.  Problem solved.  Many thanks!

--

Quote:>Rouben Rostamian enlightened us with:
>> I'd appreciate any additional suggestions.

>Suggestion: DO NOT put your real email address in your signature, unless
>you want to receive A LOT more spam.

I know, but not much spam gets to me; I have a good set of spam filters.

But out of respect for your suggestion, I will not put my email address
in the bottom of this message.  I cannot do much about the address
appearing in the header though.

-- Rouben Rostamian

Rouben Rostamian enlightened us with:

Quote:> I know, but not much spam gets to me; I have a good set of spam filters.

Still, the spam is being sent to you, thus wasting bandwidth that could
have been used for something actually useful.

Quote:> But out of respect for your suggestion, I will not put my email
> address in the bottom of this message.

Thank you, that's nice of you.

Quote:> I cannot do much about the address appearing in the header though.

Yes, you can. Remember when you set up your news client, where you had
to put in your name and email address? Guess what, you can lie and live
with it ;-)

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?

Thanks for the pointer to the discussion thread and the program.  Both
were enlightening.

The hack in reducebind.c sometimes works and sometime doesn't, just as
its author's comment says.

For me it worked successfully on a simple "hello world" program.  But
it did not work on the larger program which initiated this thread.  Well,
actually it worked and produced a statically linked executable, but when
the executable is run, it crashes and dumps core.

--