From Alain.Picard at memetrics.com Mon Dec 17 23:17:23 2007 From: Alain.Picard at memetrics.com (Alain Picard) Date: Tue, 18 Dec 2007 10:17:23 +1100 Subject: [cl-gd-devel] Premature loading of GD library can cause problems Message-ID: <87ve6wx664.fsf@memetrics.com> Dear all, At the end of init.lisp, there is a line, at toplevel, like so: (load-gd-glue) This can cause problems under certain scenarios; e.g. using Lispworks with a delivered application, on a system different from where the application was delivered. What we do, for example, is this: - app starts - set up some logical translations, from current working directory or an environment variable, say XOS_HOME - push "XOS:LIBS;" onto the list of *shared-library-directories* - call (load-gd-glue) to initalize GD. Now, in LW 5, this is failing, because in uffi, the call to load-foreign-library ends up calling #+lispworks (fli:register-module module :real-name filename :connection-style :immediate) which tries to load the library on a path which does not exist on the remote host. This all happens even before the delivered MAIN function has a chance to run and set things right. I'm expecting that LW4 and LW5 are doing something different internally which is causing this bug (behaviour?) to only manifest now. I'm not completely clear in my mind who's "fault" this situation is; I think I can see that SBCL/CMUCL users, who might tend to not deliver runnable images, but rather the core + fasls, would want the current behaviour; i.e. loading init.lisp causes the GD library to get loaded, but it seems onerous to force this choice onto everyone. For now, I have no choice but to modify my copy of cl-gd to comment out this line, something I prefer not to do when tracking 3rd party sources. Does anybody have an opinion on this situation? I think I myself, as library author, would omit the (load-gd-glue) call, and leave that to users to put in their own files at toplevel if so they wish. Are there any other "good" solutions? Cheers, Alain Picard -- Please read about why Top Posting is evil at: http://en.wikipedia.org/wiki/Top-posting and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html From edi at agharta.de Mon Dec 17 23:33:59 2007 From: edi at agharta.de (Edi Weitz) Date: Tue, 18 Dec 2007 00:33:59 +0100 Subject: [cl-gd-devel] Premature loading of GD library can cause problems In-Reply-To: <87ve6wx664.fsf@memetrics.com> (Alain Picard's message of "Tue, 18 Dec 2007 10:17:23 +1100") References: <87ve6wx664.fsf@memetrics.com> Message-ID: On Tue, 18 Dec 2007 10:17:23 +1100, Alain Picard wrote: > Does anybody have an opinion on this situation? Hi Alain, the situation you're encountering is basically just a "historical" remnant. If you'll search the UFFI mailing list archives from around 2005, you'll find out that I was the one who modified UFFI to make application delivery without hard-coded paths even possible. You can now (in UFFI) specify a library simply as "foo.so" or "foo.dll" and it will be searched for in the operating system's standard locations. However, I had written CL-GD a) before I made this change and b) even before I started to use LispWorks as my main Lisp. And I haven't used CL-GD much since. So, yes, if you want to send a patch to a) defer loading of the library and to b) make the location of the library something the OS should take care of, I'm all for it - please send a patch. I'm just too busy right now to fix this myself and, as I said, this doesn't have very high priority for me. Thanks, Edi. http://weitz.de/patches.html From Alain.Picard at memetrics.com Mon Dec 17 23:47:56 2007 From: Alain.Picard at memetrics.com (Alain Picard) Date: Tue, 18 Dec 2007 10:47:56 +1100 Subject: [cl-gd-devel] Premature loading of GD library can cause problems In-Reply-To: (Edi Weitz's message of "Tue\, 18 Dec 2007 00\:33\:59 +0100") References: <87ve6wx664.fsf@memetrics.com> Message-ID: <87r6hkx4r7.fsf@memetrics.com> Edi Weitz writes: > So, yes, if you want to send a patch to a) defer loading of the > library and to b) make the location of the library something the OS > should take care of, I'm all for it - please send a patch. I'm just > too busy right now to fix this myself and, as I said, this doesn't > have very high priority for me. Fantastic. I just wanted to make sure there was at least agreement "in principle" that this was the right thing to do. Cheers, --ap