On Thu, Dec 29, 2005 at 01:45:55PM -0600, Matt England wrote:
> Sarge-built binaries running on Woody systems:
>
> Is this feasible?
>
> I'm not talking about package management...just the raw, binary.
>
> Are dynamic-library-management tricks needed? Does the Debian testing
> authority (or whoever is given responsibility of anointing Debian releases
> for distribution) make any attempt at backwards compatibility for this kind
> of stuff?
>
> As per similar motivation for my previous redhat-on-Debian binary porting
> conversation: I'm hoping that one Debian build will work on many Debian
> systems.
>
> Can I at least count on a Woody-built binary working ok on a Sarge-based
> system? In this context, how far "back" can I go to get "forward"
> compatibility? (ie, how many revs before Sarge can I go back to "build on"
> and still get Sarge compatibility?)
>
> If there are reasons why the answer is "depends" instead of a flat "yes" or
> "no": I would love to know these reasons. This is what I'm specifically
> hunting for.
The short answer is somewhere in between "no" and "depends"...
All in all, running binaries from a significantly newer system on an
older one is something you really want to avoid, unless you have very
good reasons for doing so. Any approach to work around the various
problems would be rather cumbersome and ugly. This really cannot be
recommended under most any circumstance, at least not if the goal is to
have a single binary that'll "just run" out of the box, on any system.
IOW, the ultra short answer is: forget about any such endeavour :)
Of course, it depends on what you're trying to achieve. If you want to
run a sarge program as it is, without any tweaking, on a woody system,
the answer is a clear "no" for any dynamically linked binary. Beyond
that, there's no generic answer that would apply to every program.
For example, let's take the rather basic "ls" program. If you try to
run a sarge-built binary on a woody system you get
$ /sarge/bin/ls
/sarge/bin/ls: error while loading shared libraries: libacl.so.1: cannot open
shared object file: No such file or directory
As you can easily see, it's missing some library. More importantly, if
you do an "ldd"
$ ldd /sarge/bin/ls
/sarge/bin/ls: /lib/libc.so.6: version `GLIBC_2.3' not found (required by
/sarge/bin/ls)
librt.so.1 => /lib/librt.so.1 (0x4001a000)
libacl.so.1 => not found
libc.so.6 => /lib/libc.so.6 (0x4002c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40149000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
you also see that, in addition to the missing lib, there's a version
problem with /lib/libc.so.6, because the libc from woody is too old.
Now, ls isn't fancy at all. It's not too hard to imagine what you'd
get if you were to run a more complex application.
If you really need to do something like that, you essentially have the
following options:
(1) distribute/install all required newer libs on woody, and
(a) run the program via chroot, or
(b) fiddle with the lib paths (using LD_LIBRARY_PATH, LD_PRELOAD, etc.)
(2) recompile the program and
(a) link everything statically, or
(b) link dynamically against the new libraries in some special
location - including libc.so and ld.so (!) - and ship them
together with the application
The latter options, of course, presume that you in fact do have the
choice to recompile/relink the application -- as for example, when you
desperately want to run a new application on an outdated system (that
you can't upgrade for some reason), but otherwise don't care about
being able to run that same binary on a new system.
None of these approaches (maybe except static linking - to some degree)
achieve to create a single binary that'll just run everywhere.
Also, fiddling with the lib paths would soon get ugly, in particular
because the path to the dynamic linker/loader (/lib/ld-linux.so.2) is
hardcoded in every binary. While you could still run a simple binary
directly via
$ LD_LIBRARY_PATH=/sarge/lib /sarge/lib/ld-linux.so.2 /sarge/bin/ls
or
$ /sarge/lib/ld-linux.so.2 --library-path /sarge/lib /sarge/bin/ls
things would get rather ugly if you were to try running some program
which itself is executing some other binary. For example, assume you
wanted to check dynamic library binding, using the ldd that belongs to
the new system. As ldd is a shell script, you might think one of the
following would work
$ LD_LIBRARY_PATH=/sarge/lib /sarge/lib/ld-linux.so.2 /sarge/bin/sh
/sarge/usr/bin/ldd /sarge/bin/ls
/sarge/bin/ls: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required
by /sarge/lib/libc.so.6)
/sarge/bin/ls: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required
by /sarge/lib/libpthread.so.0)
librt.so.1 => /sarge/lib/librt.so.1 (0x40014000)
libacl.so.1 => /sarge/lib/libacl.so.1 (0x40027000)
libc.so.6 => /sarge/lib/libc.so.6 (0x4002f000)
libpthread.so.0 => /sarge/lib/libpthread.so.0 (0x40162000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libattr.so.1 => /sarge/lib/libattr.so.1 (0x401b3000)
or
$ /sarge/lib/ld-linux.so.2 --library-path /sarge/lib /sarge/bin/sh
/sarge/usr/bin/ldd /sarge/bin/ls
/sarge/bin/ls: /lib/libc.so.6: version `GLIBC_2.3' not found (required by
/sarge/bin/ls)
librt.so.1 => /lib/librt.so.1 (0x4001a000)
libacl.so.1 => not found
libc.so.6 => /lib/libc.so.6 (0x4002c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40149000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
However, when you look closely, it doesn't quite work as intended...
I won't go into how you might fix those problems -- I guess it
suffices to demonstrate that this isn't the way to go ;)
The problem with the chroot, OTOH, is that the command needs to be run
as root, but you don't always want to run the actual application as
root. In order to su to some regular user before running the program,
you'd have to duplicate all the related libs and config files within
the chroot (PAM, shadow, homedir, dotfiles and stuff), or come up with
some other homebrewn mechanism to achieve a similar effect...
Whatever you do, for any non-trivial application, you'd find yourself
installing half of the new system within one or more subdirectories of
the old system... Building dedicated binaries for each target system
somehow seems easier under most circumstances.
This isn't debian-specific. You'd find similar problems on any
platform. The faster evolving a system is, the more problems you're
likely to encounter with binary compatibilty across releases.
Also, it's not only about libraries, the kernel does play an important
role, too...
OK, I'll leave it at that for now.
Maybe you could elaborate on what exactly you're trying to do?
You know... specific questions, specific answers; generic questions,
generic answers :)
Cheers,
Almut
PS: A while ago, I posted some comments here on a related question,
i.e. how to explicitly link stuff against a libc that's older than the
one supplied with the system. It might also be of interest in the
wider vicinity of the issue at hand.
http://lists.debian.org/debian-user/2005/11/msg01591.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
