unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: <dsmich@roadrunner.com>
To: Eli Zaretskii <eliz@gnu.org>, Mark H Weaver <mhw@netris.org>
Cc: guile-user@gnu.org
Subject: Re: guile-2.0 on mingw: the sequel
Date: Sun, 25 Aug 2013 19:24:17 -0400	[thread overview]
Message-ID: <20130825232417.TCPTK.135132.root@cdptpa-web34-z02> (raw)
In-Reply-To: <87r4dh8n24.fsf@tines.lan>


---- Mark H Weaver <mhw@netris.org> wrote: 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Mark H Weaver <mhw@netris.org>
> >> Cc: godek.maciek@gmail.com,  guile-user@gnu.org
> >> 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	other threads:[~2013-08-25 23:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22 20:25 guile-2.0 on mingw: the sequel Panicz Maciej Godek
2013-08-23  6:38 ` Eli Zaretskii
2013-08-23  9:29   ` Panicz Maciej Godek
2013-08-23 10:16     ` Eli Zaretskii
2013-08-23 20:14       ` Panicz Maciej Godek
2013-08-24  6:31         ` Eli Zaretskii
2013-08-24  8:05           ` Panicz Maciej Godek
2013-08-25 15:26             ` Eli Zaretskii
2013-08-25 16:59               ` Mark H Weaver
2013-08-25 17:47                 ` Eli Zaretskii
2013-08-25 19:03                   ` Ludovic Courtès
2013-08-25 19:34                   ` Mark H Weaver
2013-08-27 21:51                   ` Panicz Maciej Godek
2013-08-26 13:28                 ` Eli Zaretskii
2013-08-23 15:13     ` Mark H Weaver
2013-08-23 15:34       ` Eli Zaretskii
2013-08-25 18:59         ` Ludovic Courtès
2013-08-25 21:19           ` Mark H Weaver
2013-08-26  2:35           ` Eli Zaretskii
2013-08-25 19:50         ` Mark H Weaver
2013-08-25 19:56           ` Mark H Weaver
2013-08-25 20:33             ` Eli Zaretskii
2013-08-25 20:40               ` Eli Zaretskii
2013-08-25 21:42               ` Mark H Weaver
2013-08-25 23:24                 ` dsmich [this message]
2013-08-26  2:44                   ` Eli Zaretskii
2013-08-26  5:56                     ` Mark H Weaver
2013-08-26  6:26                       ` Mark H Weaver
2013-08-26 13:10                       ` Eli Zaretskii
2013-08-26  2:40                 ` Eli Zaretskii
2013-08-25 20:32           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130825232417.TCPTK.135132.root@cdptpa-web34-z02 \
    --to=dsmich@roadrunner.com \
    --cc=eliz@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).