guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile-2.0 on mingw: the sequel


From: dsmich
Subject: Re: guile-2.0 on mingw: the sequel
Date: Sun, 25 Aug 2013 19:24:17 -0400

---- Mark H Weaver <address@hidden> wrote: 
> 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.

Linux (well, glibc) has dladdr http://linux.die.net/man/3/dladdr which could
be used I guess.  But that's not POSIX.

On windows, I think you call GetModuleFileName() with the handle that was 
passed to DllMain().
Is it possible for libguile to do that?

But there are fundamental differences in the way 
applications/libraries/packages are places on windows and POSIX and POSIX-like 
systems.

Seems like most windows apps install everything into their own subtree.  The 
main application is not even on the system PATH!

On a POSIXy system, there are shared places for config files, libraries, 
documentation, and so on.  It's just different.  I don't see why we would need 
to be "relocatable" here.

My $.02
  -Dale






reply via email to

[Prev in Thread] Current Thread [Next in Thread]