Re: guile-2.0 on mingw: the sequel

[Mark H Weaver]

Eli Zaretskii <address@hidden> writes:

>> From: Mark H Weaver <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Sun, 25 Aug 2013 15:56:53 -0400
>> 
>> Remember that Guile is a library, not just an executable.  So argv[0]
>> could point to any arbitrary executable that's linked with libguile.
>
> We can provide an API for passing to the library the root of its
> installation.

I suppose, but that assumes that the main program knows the location of
the libguile installation it's linked to.  How would it know this?  In
the common case on POSIX, the dynamic linker takes care of finding a
suitable copy of libguile, drawing from sources such as /etc/ld.so.conf,
/etc/ld.so.conf.d/*, LD_LIBRARY_PATH, rpaths, etc.  How can the main
program know?

> And btw, how is this different from GCC looking for its libgcc or GDB
> looking for its Python scripts?

GCC and GDB are programs, not libraries.  Finding out the location of
the current executable is a much easier problem than finding out the
install prefix of a particular library.

> An executable linked with libguile will either be in /usr/bin or
> somesuch, i.e. close to /usr/lib where libguile lives; or it will be
> in some random place under the user's home directory, in which case
> either libguile is in the default place, or it is near the binary.
> The latter case is precisely the additional feature where looking for
> the library nearby will be a benefit.

You're making a lot of very dubious assumptions here.  I'm uncomfortable
advertising a new feature for Guile that is impossible to implement
robustly.  If it has to make assumptions such as "the libguile library
is probably near the binary", it is likely to fail in many cases.

> It's true that this is not 100% bulletproof on Posix, but it's close.

So far, I've not seen a solution that's anywhere near close to being
correct on POSIX.  All I've seen is a bunch of very dubious guesses.

> And when it doesn't work, we didn't lose anything, we are just back to
> where we are now, right?

I disagree.  If we advertise a new feature that cannot work without
making dubious assumptions, then we're making promises we can't keep.
That's a step in the wrong direction, IMO.

    Regards,
      Mark