Binary relocatability
Mike Hearn <[email protected]>
| Newsgroups | gmane.linux.lsb.discuss |
|---|---|
| Message-ID | <[email protected]> |
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