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
next prev parent 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).