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

[Hongli Lai <h lai chello nl>]

OK I can't stand it anymore. I'll jump in too.

Enrico Weigelt:
Have you ever considered average desktop users? You know the kind of 
people the GNOME project is targeting? Those people don't have compile 
farms. They don't want to compile software - they shouldn't have to 
compile software. Recompilation just to make the software being able to 
run in your home folder is not acceptable for people like my dad. Making 
symlinks is also too complicated for them. It should be automatic.

Or maybe you don't really understand the issue. Let's say you have the 
application FooBar. FooBar's uses a PNG file as an icon in it's GUI. 
When you type './configure && make install', the location 
"/usr/local/share/foobar/icon.png" is hardcoded in the binary.

So what's the big deal here? One of Linux's problems on the desktop is 
the ease of installing software. We at autopackage are making a new 
installation system for Linux, which also allows software to be 
installed to any folder (the default is ~/.local). Many end users will 
like this because they don't have to type the root password. This also 
prevents malicious software from wiping out the entire system and other 
users' data.

Anyway, back to the relocation thing. Because 
"/usr/local/share/foobar/icon.png" is hardcoded in the binary during 
compile time, FooBar can't be simply installed to ~/.local. FooBar must 
be able to know where icon.png is. This is where the proposed function 
jumps in.
FooBar finds out it's binary is /usr/local/bin/foobar. Using that 
information, it can find out that it's prefix is /usr/local. And using 
that, it can find out /usr/local/share/icon.png. Win32 software work in 
a similar way: they locate their data files relative to their own path.

Another example:
FooBar is /home/test/.local/bin/foobar.
Extract prefix -> /home/test/.local
Append data file path -> /home/test/.local/share/foobar/icon.png


> Ah ?
> where's the relation between pathes given by --bindir, --libdir
> -sysconfdir and --localstatedir ?

(Example:)
bindir = /usr/local/bin
libdir = $bindir/../lib
sysconfdir = $bindir/../etc
etc. etc.
Of course this won't work if the user specifically passed a different 
path to configure, but we can check for that.


> cant the API be just getenv() ?

No, it can't, for a few reasons:
- What when you have multiple versions of an application installed?
- Environment variables are unique to each process and are copied by 
fork(). You cannot change other process' environment variables without 
modifications to the kernel. What when you install FooBar for the first 
time? Let's say FooBar uses $FOOBAR_LOCATION. When you launch FooBar 
from the GNOME panel or KDE panel, it won't work, because GNOME/KDE 
panel don't have the $FOOBAR_LOCATION environment variable.


> No, running the binary from somewhere is now problem, but expecting the
> data being somewhere else than defined by the configure options (defaulting
> to FHS) or under the homedir, but instead somewhere relative to the
> binary is a problem for me.

As I said before, configure can check for that and disable relocation 
support.


> Perhaps a separate library can provide these features

This *can't* be in a seperated library. We've developed BinReloc, a 
small library for relocation. We talked to the Gimp maintainer. He 
doesn't want to accept it unless it's in glib!
Platform-specific stuff (with fallback, of course) has to be 
*somewhere*. If not in glib, then where else?
- Putting it in a seperate shared library will not work because people 
want to avoid dependancies.
- Putting it in a library that's supposed to be statically included 
(BinReloc) does not work because people don't want *any* 
platform-specific code (including #ifdefs).



In summary: this relocation problem is a big issue for *desktop users*. 
Average users who just want their computer to Just Work(tm), without 
having to dive into the commandline or recompile or making symlinks. Are 
you not supporting making Linux/Unix easier to use for those people?
Or do you have a better idea?