[lsb-discuss] Binary relocatability

Mike Hearn mike at theoretic.com
Thu Mar 6 12:35:52 PST 2003


OK, I think this issue is more in the scope of the LSB than the new
packaging group.

Basically, we have a problem, in that many Linux apps today use automake
macros defined in Makefile.am files to locate their data files. This
means that when you do 

./configure --prefix=/foo/bar

Not only does it alter the build system, it also ends up altering the
binaries as well. For instance, constructs like the following are
common:

Makefile.am

GLADE_DIR=$(DATA_DIR)/gnomeicu/glade

then in the code somewhere:

open_the_file( GLADE_DIR "/foo.glade" );

and the macro preprocessor expands it out. The upshot of all this is
that once you've built a binary, its prefix can't be changed. That's
lame for the following reasons:

1) In the event of a namespace collision, you can't simply move it to
/opt/some-unique-name

2) If you're not root, you can't install it to your home directory,
because all home directories obviously have different prefixes

3) Most distros don't use LVM style partition mergers. That means if you
run out of disk space, and make another partition available, you have to
recompile your apps in order to move them.

4) It makes networking harder, you can't simply mount /network/apps and
dump all your programs there for instance.

D'oh.

The problem exists because, in the absence of a generally accepted way
to actually find out where you've been installed to, it was easier to
rely on auto* magic to sort things out. The fact that it's relatively
easy to compile from source just meant the problem never really got the
attention it really needs.

For those who may not be aware, it's a quirk of UNIX that there's no API
to locate the absolute path of the binary at runtime. Windows has one,
and presumably so does MacOS. There is one on Linux, you can stat
/proc/$pid/exe which is a symlink to the binary. I don't know how
portable that is. Obviously that doesn't work for scripts, the symlink
just points to the location of the interpreter, not the script.

I don't really know if this is a job for the LSB or is just a case of
evangelism. In autopackage Hongli wrote a little library called
libprefixdb which provides some functions and a few macros to retrieve
the prefix of an application/library/script from a database. That in
turn is very simple, we just use a series of directories, symlinks and
text files as our database, so really libprefixdb is very light indeed.

However, a real solution that addresses the needs of both natively
compiled binaries and python/perl/bash scripts is needed so they can all
find auxiliary files easily.

Any ideas? Is this the sort of thing that the LSB is meant for?
thanks -mike





More information about the lsb-discuss mailing list