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

[Laszlo Peter <Laszlo Peter Sun COM>]

On Tue, 2004-04-13 at 22:53, Mike Hearn wrote:
> On Tue, 13 Apr 2004 22:14:37 +1200, Laszlo Peter wrote:
> > Hmm... it'd be great to find a platform independent
> > solution -- something that would also work on, say, Solaris (;
> 
> Well, I have no clue whether Solaris has an equivalent of /proc, but if
> not it might be good to have one.

It does, but it doesn't have "maps" or equivalent in it. 

> > Since on most Unix flavours there's no way to find the path to the
> > running binary, I think we should try something else. 
> 
> Ah, well this is the sticking point where we all start disagreeing, it

of course (;

> seems. I think hacks that rely on scanning $PATH, or trying random paths

I agree these two are bad.

> or reading config files or whatever are just really bad, and that it's the
> responsibility of the underlying OS to make this work.

Hmmm... I can't see what's so wrong with config files, though.
A single non-relocatable config file for all glib apps could
actually decrease the number of interfaces we currently support,
like GTK_PATH, GTK_DATA_PREFIX, GTK_EXE_PREFIX, GNOME_PATH...

> You work at Sun, you must be able to file a bug report against the Solaris
> kernel/rtld if there is no way to get the absolute location of a binary,
> right? How are Solaris binaries supposed to do this currently: surely not
> by having hundreds of environment variables and config files?

The rtld has a solution for this: you can use $ORIGIN in the
runpath. 

The problem with the binary location is that there is no
standard for doing this. The fact that Linux and Win32 have
interfaces (two different ones) for this doesn't make it
standard at all and the Solaris folks don't like adding
unstable/non-standard interfaces so I see little chance to get this
added and even less to get it backported to older releases...

And then we are only talking about Solaris here, not any other
Unix flavours.

> > I believe this proposal addresses all the issues in the original post,
> > except when a non-root user wants to install something. Something like a
> > dot-file in $HOME could help. It would only be used if (getuid () ==
> > geteuid ()).
> 
> Well, it does, but this seems an awful hack. Having a config file tell the
> program where it is isn't really portable to Windows either, to be frank.

Okay, I admit I don't know much about Windows so I have to take your
word on this (;

> > This is what much of the GNOME code currently does: You put
> > -DFOODIR=\"$(foodir)\" in your Makefile and then you have something like
> > 
> > 	FOODIR "/relative/path/to/file"
> > 
> > in the C code. Instead, you could just use
> > 
> > 	g_find_file ("foodir", "/relative/path/to/file")
> 
> I think that's asking for incorrect paths, to be honest, but I don't know
> how easy it is to get new features into Solaris. From the fact that you
> haven't even raised the possibility, I'm guessing the answer is that it's
> not easy :(

Features, yes. Unstable interfaces into the kernel -- really hard.

Laca

> FYI, the current binreloc API (which is standalone) allows you to change:
> 
>         FOODIR "/relative/path/to/file"
> 
> with
>         FOODIR( "/relative/path/to/file" )
> 
> and the returned string can be used until the next invocation of the macro
> at which point it's freed. It makes memory management a bit simpler. This
> is of course thread safe.
> 
> I'm not proposing that sort of API for glib, but I thought it might
> provide a useful data point.
> 
> thanks -mike