Mark H Weaver <m...@netris.org> writes:
> Eli Zaretskii <e...@gnu.org> writes:
>
>>> From: Mark H Weaver <m...@netris.org>
>>> Cc: Eli Zaretskii <e...@gnu.org>, "guile-user\@gnu.org"
>>> <guile-user@gnu.org>
>>> Date: Fri, 23 Aug 2013 11:13:19 -0400
>>>
>>> Of course, ideally we would allow the entire Guile install to be freely
>>> relocatable, as Windows users have come to expect. This would require
>>> some help from a Windows developer.
>>
>> Why should this feature be limited to Windows builds of Guile? Why
>> not make it work for Posix platforms as well? Some other projects
>> already do, they use argv[0] and PATH search to find the place where
>> the executable is installed, and record relative file names from
>> there.
>
> Well, that's not generally how things are done on POSIX systems, and
> furthermore I don't see how this could be made to work reliably on
> POSIX. The location of the Guile executable is sometimes not found in
> either argv[0] or PATH. For example, if you run the following script:
>
> #!/usr/local/bin/guile -s
> !#
>
> (format #t "~s~%" (program-arguments))
>
> argv[0] will point to the script, not the Guile executable. I suppose
> we could detect if argv[0] points to a script and read the shebang (and
> iterate, if the shebang points to another script), but even that doesn't
> cover all cases. It's possible to pass any arbitrary value for argv[0]
> using the 'exec' family of system calls.
I forgot to mention a much more common case that would cause problems.
Remember that Guile is a library, not just an executable. So argv[0]
could point to any arbitrary executable that's linked with libguile.
There are many different mechanisms available to do the linking,
including static linking, LD_LIBRARY_PATH, rpaths, etc. Trying to
portably figure out which copy of libguile was used, and where it is
located, is a can of worms, to put it mildly.
Having said that, we should probably come up with a solution for
relocatable builds on MacOS X as well.
Regards,
Mark
