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

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 ?

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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]