Re: guile-2.0 on mingw: the sequel

[Mark H Weaver]

Mark H Weaver <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>
>>> From: Mark H Weaver <address@hidden>
>>> Cc: Eli Zaretskii <address@hidden>,  "address@hidden" <address@hidden>
>>> 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