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

[Enrico Weigelt <weigelt metux de>]

* Mike Hearn <mike navi cx> [2004-04-09 15:30:38 +0100]:

<snip>
> Binaries of programs are easier to use when they can be installed
> to any path. Use cases included:
What exactly is the problem ?
Finding the right .so's - isn't this the job for ld.so ?

<snip>
> - 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.
Different prefixes and use mount --bind ?

<snip>
> - 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)

Why not let the machine do the recompile work ?

In normal cases (i.e. workstation), the build layout would be common FHS.
But you could also put every application into its own prefix and let a 
small shellscript throw symlinks or adjust pathes ?

For example autoshit understands --prefix, --sysconfdir, --localstatedir
This should be enough.

I'm using this method i.e. for larger packages which may exist in 
different versions on the system, like postgresql or httpd.
So I've got /usr/lib/pgsql=7.4.1.0 and /usr/lib/pgsql=7.3.2.0 and a symlink
/usr/lib/pgsql to the current production version.

This way is also optimal for automated packaging:
pgsq-7.3 and pgsql-7.4 are fundamentally different packages, which dont 
have any relation (no dependencies, no exclusions). And there's also a 
package pgsql (version 7.3 or 7.4), which depends the right pgsql-xxx and 
contains the symlink to the right tree and some migrations scripts.

That's the only clean way I can imagine for MVCC at packaging level.

> - 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.

Why not recompiling with the right --prefix ?

> 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.
What exactly do you need it for ?

You probably need to find some resource files, configuration, etc.
Where could the location of the binary help ?

<snip>
> 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.
argv[0] is exactly what you'd expect: the first parameter, which is the 
command itself. If the binary was called over some alias (i.e. a symlink),
then it does of course _not_ contain the actual binary file name.

<snip>
> The solution:
> 
> It would be nice if glib could provide something like the following API:
> 
> gboolean g_get_absolute_path(gchar *fallback, gchar **out);
Could this please be located in another library, and not glib.so / glib.h ?
Its already too big.

You probably dont want to reimplement Qt ;-)

<snip>
> 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
btw: is there any hope for getting rid of the autoshit stuff in near
future ? I've made suggestions on the gtk-list some years ago (these days
I also voted for garbage collection), but these days nobody listened :(

<snip>
> .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.

What exactly do these codeparts ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact metux de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------