Update: the described workaround fails because at that point the value of ext:*command-line-utility-name* is still the one from the _previous_ run (from which the dump was created). Anyway, doing the fixup and reload-global-table from the init-function seems to work for me, so that's what I'm using right now. Of course, this would break if reload-global-table was at some point added to the *after-save-initializations* by the lisp itself.
Cheers, Andreas -- Attached file included as plaintext by Listar -- -- File: access to ext:*command-line-switches* from reload-global-table? Return-path: <[email protected]> Envelope-to: [EMAIL PROTECTED] Delivery-date: Tue, 07 Feb 2006 17:02:43 +0100 Received: from mail.cs.uni-sb.de ([134.96.254.200] ident=[Wjq/Itkaf1UK0Q9LfXflzaVgfy8F8DwJ]) by monster2.ags.uni-sb.de with esmtp (Exim 4.43) id 1F6VIh-0003Zd-Dy for [EMAIL PROTECTED]; Tue, 07 Feb 2006 17:02:43 +0100 Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mail.cs.uni-sb.de (8.13.5/2006012700) with ESMTP id k17G3Aca029017 for <[EMAIL PROTECTED]>; Tue, 7 Feb 2006 17:03:10 +0100 (CET) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id k17G0PXu046443; Tue, 7 Feb 2006 17:00:26 +0100 (CET) (envelope-from [email protected]) Received: with LISTAR (v1.0.0; list cmucl-help); Tue, 07 Feb 2006 17:00:25 +0100 (CET) Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id k17G0DZF046426 for <[email protected]>; Tue, 7 Feb 2006 17:00:13 +0100 (CET) (envelope-from [EMAIL PROTECTED]) Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by uni-sb.de (8.13.5/2006012700) with ESMTP id k17G091h006523 for <[email protected]>; Tue, 7 Feb 2006 17:00:09 +0100 (CET) Received: from monster2.ags.uni-sb.de (monster2.ags.uni-sb.de [134.96.236.112]) by mail.cs.uni-sb.de (8.13.5/2006012700) with ESMTP id k17G087l028702 for <[email protected]>; Tue, 7 Feb 2006 17:00:08 +0100 (CET) Received: from pan.ags.uni-sb.de ([134.96.236.209]) by monster2.ags.uni-sb.de with esmtp (Exim 4.43) id 1F6VFj-0003Xv-3P for [email protected]; Tue, 07 Feb 2006 16:59:39 +0100 Message-ID: <[EMAIL PROTECTED]> Date: Tue, 07 Feb 2006 17:00:08 +0100 From: Andreas Franke <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: [email protected] Subject: access to ext:*command-line-switches* from reload-global-table? Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-CRA-SPAM-P: nothing, saved by "Hello," X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on schlepper.zs64.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-listar-version: Listar v1.0.0 Sender: [email protected] Errors-to: [email protected] X-original-sender: [EMAIL PROTECTED] Precedence: bulk X-list: cmucl-help X-DCC-UTR-Metrics: mail 1060; Body=1 Fuz1=1 Fuz2=1 Hello, in 19c, ext:*command-line-switches* is still nil when the first function from ext:*after-save-initializations* is run; by the time the read-eval-print loop is running, it works as advertised. Is there an alternative way to access the path of the current lisp image (the value of the "core" switch) at that early point, or possibly from a later stage during the *after-save-initializations*? Background: I'd like to distribute a dump that depends on foreign libraries, together with these libraries. The absolute path where the dump will reside on the target system is not known in advance. The location of the foreign libraries will be known relative to the location of the dump. My idea was to fixup the lib-paths before reload-global-table (see http://thread.gmane.org/gmane.lisp.cmucl.general/1365 ) depending on the value of the "core" switch, but this does not seem to work because that info is not available at that point. A possible workaround could be to use the value of ext:*command-line-utility-name* (which is indeed available even at that early point) as base path. This should work because the lisp executable will be distributed together with the dump, too. On the downside, this would require us to copy the lisp executable into the dump directory even in the non-distribution case, and always run it from there. Is this the recommended way of doing this, or is there a better way? Thanks in advance, Andreas
