From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: guile-2.0 on mingw: the sequel Date: Sun, 25 Aug 2013 17:42:27 -0400 Message-ID: <87r4dh8n24.fsf@tines.lan> References: <83vc2wj4hz.fsf@gnu.org> <877gfccueo.fsf@tines.lan> <83d2p4ifow.fsf@gnu.org> <874nada6t1.fsf@tines.lan> <87zjs58ry2.fsf@tines.lan> <83eh9hh5n4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377466980 25069 80.91.229.3 (25 Aug 2013 21:43:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Aug 2013 21:43:00 +0000 (UTC) Cc: guile-user@gnu.org To: Eli Zaretskii Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Aug 25 23:43:00 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDi5M-0007FI-IR for guile-user@m.gmane.org; Sun, 25 Aug 2013 23:43:00 +0200 Original-Received: from localhost ([::1]:47747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDi5L-0005ck-W1 for guile-user@m.gmane.org; Sun, 25 Aug 2013 17:42:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDi5A-0005a9-1d for guile-user@gnu.org; Sun, 25 Aug 2013 17:42:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDi54-0008Et-Kw for guile-user@gnu.org; Sun, 25 Aug 2013 17:42:48 -0400 Original-Received: from world.peace.net ([96.39.62.75]:40328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDi54-0008Eo-Gt; Sun, 25 Aug 2013 17:42:42 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VDi4x-00087k-G6; Sun, 25 Aug 2013 17:42:35 -0400 In-Reply-To: <83eh9hh5n4.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 25 Aug 2013 23:33:51 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10710 Archived-At: Eli Zaretskii writes: >> From: Mark H Weaver >> 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. > 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