Re: Binary relocatability

Mike,
Thanks for bringing up this problem.
If one were to take something from the appdirs discussion some weeks back,
it would be the lack of such support on linux, etc.

I believe Darwin does it by building the library loading scheme to be relative to
the top level app dir.

For most linux it might suffice to have thee executable in /prefix/bin look into
/prefix/lib for the library first, then whats specified in ld.so.conf. OSX does
appdir/current where current lis a link to version number so one can have
multiple major and minor number based library versions in the same appdir, or for that matter, /usr/lib.

Rahul

On Thu, Mar 06, 2003 at 08:35:52PM +0000, Mike Hearn wrote:
> 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
> 
> 
> _______________________________________________
> lsb-discuss mailing list
> [email protected]
> http://freestandards.org/mailman/listinfo/lsb-discuss