[cl-gd-devel] Premature loading of GD library can cause problems

Alain Picard Alain.Picard at memetrics.com
Mon Jan 7 05:37:21 UTC 2008


Edi Weitz <edi at 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




More information about the Cl-gd-devel mailing list