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: Mon, 26 Aug 2013 01:56:19 -0400 Message-ID: <87sixx6lmk.fsf@tines.lan> References: <20130825232417.TCPTK.135132.root@cdptpa-web34-z02> <837gf9gogq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377496613 25692 80.91.229.3 (26 Aug 2013 05:56:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2013 05:56:53 +0000 (UTC) Cc: guile-user@gnu.org To: Eli Zaretskii Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Aug 26 07:56:55 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 1VDpnK-0007mw-8s for guile-user@m.gmane.org; Mon, 26 Aug 2013 07:56:54 +0200 Original-Received: from localhost ([::1]:49151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDpnJ-0007wS-6V for guile-user@m.gmane.org; Mon, 26 Aug 2013 01:56:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDpn7-0007vR-4f for guile-user@gnu.org; Mon, 26 Aug 2013 01:56:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDpn2-0006fM-CI for guile-user@gnu.org; Mon, 26 Aug 2013 01:56:41 -0400 Original-Received: from world.peace.net ([96.39.62.75]:40655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDpn2-0006ez-71; Mon, 26 Aug 2013 01:56:36 -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 1VDpmt-0000zi-7W; Mon, 26 Aug 2013 01:56:27 -0400 In-Reply-To: <837gf9gogq.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 26 Aug 2013 05:44:53 +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:10715 Archived-At: Eli Zaretskii writes: >> Date: Sun, 25 Aug 2013 19:24:17 -0400 >> From: >> Cc: guile-user@gnu.org >> >> On windows, I think you call GetModuleFileName() with the handle that was passed to DllMain(). >> Is it possible for libguile to do that? > > I see no reasons why not. Yes, that much we can agree on. Since the Windows API provides a reliable method to tell us the location of the libguile library, we can certainly use that to find the rest of the Guile installation. >> 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. > > One reason to be "relocatable" is to be able to easily run > applications from the build or source tree, while a different version > is installed on the system. We already have a solution for this. Just run "meta/guile" from the build directory, or more generally "meta/uninstalled-env". >> From: Mark H Weaver >> Cc: godek.maciek@gmail.com, guile-user@gnu.org >> Date: Sun, 25 Aug 2013 17:42:27 -0400 >> >> Eli Zaretskii writes: >> >> > 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? I explained that in the part of my message that you omitted from your quotation. I can think of one notable case where the program would know where libguile is located: when the program bundles its own copy of Guile, and therefore assumes that libguile and the program are always moved together as an atomic unit. This practice is frowned upon on most POSIX systems (and rightfully so), but I guess it's fairly common on Windows and MacOS X systems. In cases where libguile is installed independently, and where libguile has been moved since the program was built, there's no reason why the program would know where libguile is located. Every time the program is run, the dynamic linker searches for libguile in many different places. The set of places it looks depends on the platform. >> > 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. Yes, and those executables (GCC and GDB) can reasonably assume that their auxilliary files are always installed in the same prefix as the executables, since they are part of the same package. However, libguile and some-program-that-uses-libguile are _not_ part of the same package. There's no reason to assume that they'll be installed in the same prefix, and they could be moved independently of each other. When the program is compiled, of course it needs to know where libguile is located, but since we're talking about making these packages relocatable, there's no guarantee that libguile will be in the same place as it was when the program was compiled. >> > 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. Okay, again: How exactly do you suggest we determine the location of the libguile installation from an arbitrary executable that links to it? Mark