Proposal: an addition to glib for getting the absolute path of the current binary.

[Mike Hearn <mike navi cx>]

Hi,

After some discussion on #gimp after a friend of mine submitted a patch to
make it binary relocatable on Linux (ie binaries can be installed to any
prefix), Tim suggested I write a proposal here so everyone, especially
Owen who apparently has expertise in this area, can comment.

The justification:

Binaries of programs are easier to use when they can be installed
to any path. Use cases included:

- User ran out of disk space on their primary / or /usr partition, so
added a new hard disk mounted at /mnt/new-hard-disk. They want to be able
to install relocatable RPMs and other types of binary package to their new
hard disk.

- Network administrator wishes to install binaries to a directory on his
server and then have it mounted at /some-app-server on the client
machines. He doesn't want to have to recompile all the software (which
might not even be possible)

- User has an account on a machine and does not have root, but wishes to
install software. Relocatable binaries let them install software to
~/.local or some similar prefix that they have write access to.

The problem:

Only Win32 and Linux, as far as I know, provide a way to get the absolute
path of a given binary. On Linux you can read /proc/self/exe, or for a way
that works for libraries as well, /proc/self/maps. On Win32 there is a
GetModuleFilename() API.

Unfortunately, other systems often do not expose this information. Call it
a deficiency of POSIX, a quirk of history, or whatever, but the only way
to figure out the absolute path of yourself on these systems is to scan
the PATH. argv[0] is not always absolute so this can only be used as a
clue, rather than a full solution. Scanning the path can get it wrong in a
large variety of cases.

The solution:

It would be nice if glib could provide something like the following API:

gboolean g_get_absolute_path(gchar *fallback, gchar **out);

which takes a fallback string (typically would be the PREFIX macro as
defined by the build system on UNIX) and a pointer to a pointer which is
set either to be g_strdup(fallback) on systems where this information is
not available, or the absolute path of the calling module on systems where
it is.

By calling module, I mean that if the function is called from inside a
library, the absolute path to that library is returned, NOT the path to
the main executable.

The return is just true if the information was read from the OS, and false
if the fallback was used. It can normally be ignored, but might be useful.

Tim Janik raised the point that this, by itself, may not be enough to
allow programs to be installed to any path because of things like libtool
.la files and old-style gnome mime handler files. However, for many apps
it *is* useful, would reduce code duplication - currently many programs
like Gaim have separate codepaths for their win32 port here. In time other
programs that make assumptions about or embed absolute paths in their data
files can be fixed.

Thoughts? I am willing to write this function if an acceptable API can be
found.

thanks -mike