[cl-gd-devel] Premature loading of GD library can cause problems
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
On Tue, 18 Dec 2007 10:17:23 +1100, Alain Picard <Alain.Picard@memetrics.com> 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
Edi Weitz <edi@agharta.de> 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
Edi Weitz <edi@agharta.de> 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.
Sigh. I looked at this, and coudn't find a way that woudn't potentially damage all the other users on other platforms. The closest I could see was to comment out the top level call to (LOAD-GD-GLUE), but that would break existing users; and I can't put in a variable like (defvar *inhibit-automatic-dll-registration* nil) in specials.lisp because there is no time between loading specials.lisp and init.lisp that the user can use to turn on the inhibition. So, I believe the correct thing is to simply remove the call to LOAD-GD-GLUE, but since it's not my library, and I don't know what the bulk of users are doing (I'm imagining a zillion happy hamsters, hacking on SBCL, blissfully unaware of this problem), I think the best thing to do at this point is to leave it alone and I'll continue with my local modification. Perhaps just a comment in init.lisp, like the following, so future poor schmucks don't have to rediscover my woes for themselves: ;;; If you are a Lispworks user, and you will be shipping a delivered application ;;; to a machine where the code will run from a different directory from where it ;;; was compiled, you will need to comment out the next line, ;;; adjust *SHARED-LIBRARY-DIRECTORIES* and call load-gd-glue when your application starts. (load-gd-glue) Sorry for the noise. :-( --alain
On Mon, 07 Jan 2008 16:37:21 +1100, Alain Picard <Alain.Picard@memetrics.com> wrote:
Sigh. I looked at this, and coudn't find a way that woudn't potentially damage all the other users on other platforms. The closest I could see was to comment out the top level call to (LOAD-GD-GLUE), but that would break existing users; and I can't put in a variable like (defvar *inhibit-automatic-dll-registration* nil) in specials.lisp because there is no time between loading specials.lisp and init.lisp that the user can use to turn on the inhibition.
With enough effort, one can probably invent some clever mechanism which utilizes ASDF for this. I hacked something similar for CLSQL some time ago: http://clsql.b9.com/manual/appendix.html#foreignlibs (Yeah, it's a bit different there because you have at least two systems. That's why I said "with enough effort"... :)
So, I believe the correct thing is to simply remove the call to LOAD-GD-GLUE, but since it's not my library, and I don't know what the bulk of users are doing (I'm imagining a zillion happy hamsters, hacking on SBCL, blissfully unaware of this problem), I think the best thing to do at this point is to leave it alone and I'll continue with my local modification.
I don't agree. Judging from the number of subscribers to this mailing list and from the amount of feedback you've gotten so far, I'd guess that the order of magnitude of users who rely on CL-GD not to break their valuable apps is more like zero. If the choice is between a) users of Lisp A may need to insert a new line into their applications and b) users of Lisp B can't use the library without local modifications, I think it is only fair to put some burden on the users of Lisp A. Besides, as I said already, I think the change you proposed is The Right Thing[TM] to do anyway.
Edi Weitz <edi@agharta.de> writes:
If the choice is between a) users of Lisp A may need to insert a new line into their applications and b) users of Lisp B can't use the library without local modifications, I think it is only fair to put some burden on the users of Lisp A. Besides, as I said already, I think the change you proposed is The Right Thing[TM] to do anyway.
Well, I'm not going to argue agains my own advice; so if you're happy burdening users with this sort of change, I'll send you a patch; but it'll be trivial: it'll basically mean * delete the (load-gd-glue) call from init * export *shared-library-directories* --ap
participants (2)
-
Alain Picard -
Edi Weitz