dynamic ELF -> static executable?

[mol...@phys.columbia.edu]

Hi,

Is there a way to combinbe a dynamic ELF executable with the shared
libraries it refers to into a static (and hence more portable) version of
the executable? The linux loader does something quite similar but I could
not coerce the linker 'ld' to do it, e.g.,

ld -Bstatic -o <static_exec> <dyn_exec> <libraries>

creates an executable that segfaults when run.

Thanks for any help or pointers,

Denes

[Paul Pluzhnikov]

mol...@phys.columbia.edu writes:

> Is there a way to combinbe a dynamic ELF executable with the shared
> libraries it refers to into a static

Yes (but it's a hack, and the resulting executable is huge):
http://groups.google.com/group/gnu.gcc.help/browse_frm/thread/7dd333be29171843

The last message in the thread refers to reducebind.c http link
which has "gone cold". Searching google for reducebind.c however
gives more locations, this one is currently alive:
http://bismark.extracon.it/linux/teso/filemirror/reducebind.c

> (and hence more portable) version of the executable?

The notion that static executables are more portable is a wrong
(or at least miguided) one. You may wish to read this thread on
the subject:
http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/3cb7d8fbf9d82d7b

> The linux loader does something quite similar but I

The linux loader does nothing of the sort.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Denes Molnar]

Dear Paul,

Thanks for the quick reply. At this point I am divided whether to proceed
with the idea at all.

The humble goal was to install VNC (at least the server) on an a SE Linux
AS 3.0 system for which there is only an unreliable 4.0.0 beta version RPM
and where anyway I am only of the hundreds of average Joe users (no root
access). I first tried to compile vnc 4.1.1 from source but turned out it
requires compilation of the full XFree tree (to get the Xvnc executable),
which is said to be complicated and fail with a fair chance. An
alternative solution could have been to take a binary from somewhere else,
say Fedora 4. The main issue there is that the SE Linux system is
glibc-2.2, while Fedora uses version 2.3. I tried including via
LD_LIBRARY_PATH all the Fedora 4 shared libraries that Xvnc is linked
against (at least as reported via ldd), and even Fedora's ld-linux.so, but
that did not work. This is why I hoped to create a static Xvnc executable
and use that one. Size is a non-issue, what matters to me is "least
action".

Now seeing all the complications, and the uncertainties with
dynamic->static conversion and portability, I think I will just try to
compile the Xvnc-patched X and see whether that works.

Too bad it looks like there is no free lunch in this business - must have
been too naive...

Denes

---------------

Email from Paul Pluzhnikov on Dec 25, 2005 at 11:48pm:

[Kasper Dupont]

Paul Pluzhnikov wrote:
>
> The notion that static executables are more portable is a wrong
> (or at least miguided) one.

Static executables can be made more portable. The problem is,
that it may be difficult to make one which is completely
static. For example if you try to statically link glibc, you
get only half of glibc linked statically, the other half is
still linked dynamically. Suddenly you have an executable
that breaks when internal glibc interfaces are changed.

If you could make a static executable, that relied only on
the user/kernel interface, it would be very portable between
different Linux versions. It is a priority for kernel
developers to keep this interface static between kernel
versions.

If you took the libc usually used with Linux 2.0, I would
expect it to work with Linux 2.6 as well. But an executable
that was statically linked against such an old libc probably
wouldn't work with the newest glibc.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

[Tim Smith]

In article
<Pine.LNX.4.62.05...@cosmos.phys.columbia.edu>,

mol...@phys.columbia.edu wrote:
> Is there a way to combinbe a dynamic ELF executable with the shared
> libraries it refers to into a static (and hence more portable) version of
> the executable? The linux loader does something quite similar but I could

How about putting the executable and all the libraries it needs in one
directory, and distributing that as a tarball. Have in there a simple
install script that can be run when the tarball is unpacked. This
script would create a little wrapper script to set up LD_LIBRARY_PATH
and then execs the executable.

--
--Tim Smith

[Paul Pluzhnikov]

Tim Smith <reply_i...@mouse-potato.com> writes:

> How about putting the executable and all the libraries it needs in one
> directory, and distributing that as a tarball.

This will not work, if one of the libraries the executable needs
is libc.so.6. The reasons (and a possible workaround) are explained
in this (rather long) thread:

http://groups.google.com/group/comp.os.linux.development.system/browse_frm/thread/c7ca9f38d355718c

[Paul Pluzhnikov]

Denes Molnar <mol...@physics.purdue.edu> writes:

> Thanks for the quick reply.

Please do not top-post.

> The humble goal was to install VNC (at least the server) on an a SE
> Linux AS 3.0 system for which there is only an unreliable 4.0.0 beta
> version RPM and where anyway I am only of the hundreds of average Joe
> users (no root access).

Your best bet is to find a binary VNC package built for glibc
which is older then the glibc installed on your "SE Linux AS 3.0"
(whatever that is).

> An alternative solution could have been to take a binary
> from somewhere else, say Fedora 4. The main issue there is that the SE
> Linux system is glibc-2.2, while Fedora uses version 2.3. I tried
> including via LD_LIBRARY_PATH all the Fedora 4 shared libraries that
> Xvnc is linked against (at least as reported via ldd),

Right. That doesn't work, as explained e.g. here:

http://groups.google.com/group/comp.os.linux.development.system/browse_frm/thread/c7ca9f38d355718c

> and even Fedora's ld-linux.so, but that did not work.

That actually might work, if you invoke Xvnc via the "magic"

/path/to/fc4/ld-linux.so.2 --library-path /path/to/fc4/libraries Xvnc

command line. I don't believe Xvnc starts any children, so the
complications mentioned in the above thread do not arise.

> Too bad it looks like there is no free lunch in this business - must
> have been too naive...

Actually, getting Xvnc compiled for glibc-2.2 should easily solve
all of your problems.

[Denes Molnar]

Hi,

>> and even Fedora's ld-linux.so, but that did not work.
>
> That actually might work, if you invoke Xvnc via the "magic"
>
> /path/to/fc4/ld-linux.so.2 --library-path /path/to/fc4/libraries Xvnc

This is almost precisely what I tried and then failed, except that I used
LD_LIBRARY_PATH. I guess it should be equivalent to the command-line
option (though with computers every bit may count :). I had to because the
glibc-2.2 loader gives some relocation error, but unfortunately with the
glibc-2.3 one the executable terminates prematurely. The most likely
problem is that Xvnc starts a window manager (twm) and also launches an
xterm on the new X server it creates.

In the end I went back to compiling XFree+Xvnc from source and it worked
without ANY problem. Just untar and make. The VNC developers must have
their reason for telling people to expect compilation problems - probably
I was just plain lucky. Anyway, problem solved at last.

Thank you all for your help, I especially learned a lot from the two refs
by Paul,

Denes