cl-gd-devel

Download

cl-gd-devel@lists.common-lisp.net

January 2008

2 participants
1 discussions

[cl-gd-devel] Premature loading of GD library can cause problems
by Alain Picard 10 Jan '08

10 Jan '08

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

2 5