Re: BinReloc functionality

[Alexandre Moreira <alexandream gmail com>]

On Thu, 19 Aug 2004 21:32:57 +0200, Christer Palm <palm nogui se> wrote:
> Alexandre Moreira wrote:
> > Is there anything like BinReloc's
> > (http://autopackage.org/docs/binreloc/) functionality  in GTK+
> > (probably Glib would be the best place for it) available to the
> > programmer ?
> >
> > If not, what are the odds that something like that would be implemented ?
> >
> 
> The problem with this is to do it in a portable way. Binreloc doesn't
> even seem to make any attempts to be portable. I've been using the
> following code to get the path of the executable:
> 
>      char buf[PATH_MAX + 1];
>      char* path = getenv("_");
>      if (!path) {
>          if (readlink("/proc/self/exe", buf, sizeof (buf)) == -1) {
>              return NULL;
>          }
>          path = buf;
>      }
>      return path;
> 
> But although that should compile on any POSIX system, there's no
> guarantee that it would actually work. Portable programs should not rely
> on beeing able to reliably determine the runtime path of its executable.
> 
> --
> Christer Palm
> 

Correcting a mistake I did while sending this message (Christer, sorry
for sending it to your address directly) I hate when I click the wrong
link... there goes the answer:

I see your point Christer, but although BinReloc doesn't attempt to be
portable at all, it is disabled by default.

You need to set a -D... flag while compiling so that it would be
used... therefore, it would (could ?) be used with other platforms in
the 'default way' and with binReloc with linux.

I am not 100% sure about this, but I might take a look.

By now I heard KDELibs has something like this and I would like to see
my 'toolkit of choice' to have such options.... I will study the
subject and post any news if anyone opposes.

BTW, although your approach may be valid for executable files, it
wouldn't work with libraries.

well... I think that's all I have to say now.

Please forgive my poor english as it is not my primary language.

Cheers,
 Alexandre Moreira.