Re: guile-2.0 on mingw: the sequel

[Eli Zaretskii]

> From: Mark H Weaver <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Sun, 25 Aug 2013 17:42:27 -0400
> 
> 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?

We are talking about the situation where libguile is _not_ installed
in the usual places.  Why would a program _not_ know where that is?

> > 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.

The issue is how to find the auxiliary files _given_ the location of
the executable, not how to find where the executable itself lives.

> > 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.

My turn to disagree.