[cffi-devel] %load-foreign-library on SBCL

[Elliott Slaughter]

On Tue, Dec 22, 2009 at 2:15 AM, Luís Oliveira <luismbo at gmail.com> wrote:

> On Tue, Dec 22, 2009 at 6:56 AM, Elliott Slaughter
> <elliottslaughter at gmail.com> wrote:
> > After what feels like beating my head against a wall for several hours,
> and
> > getting contradictory results from various attempts to boils the failure
> > down to a manageable size, I finally tried my original build recipe
> again,
> > and it just worked. I'm not really sure what to say, other than that I'm
> > really confused. I don't think the workarounds suggested by myself and
> > others are necessary, so I think we can all forget about this, at least
> > until this comes to haunt me again.
>
> This is something that definitely needs to be improved in CFFI, at
> least documentation-wise. Care to share your build recipe for dealing
> with foreign libraries?


Well, there's not really much to it, at least when it works. Basically, I
just

(asdf:oos 'asdf:load-op *some-system*)

which presumably has a dependency on lispbuilder or cl-opengl or something
else that depends on a foreign library. After than, just save the
executable,

#+sbcl (sb-ext:save-lisp-and-die #-windows "main" #+windows "main.exe"
:toplevel #'main :executable t)

The only platform where I typically have this not work is on SBCL/Windows. I
do have a little piece of initialization code to reload any foreign
libraries, but obviously that didn't help me this last time. Sometimes I
also put the dlls in the current directory, but again, I'm not sure whether
that actually helps or not.

Other than that, I've just got a makefile which builds installers for
Windows, .app files for Mac, and tarballs for Linux.

Anyway, if you are interested in looking at the entire script, see:

http://blackthorn-engine.googlecode.com/hg/dist.lisp

and the makefile (particularly the dist and install-* targets):

http://blackthorn-engine.googlecode.com/hg/Makefile

Hope that helps.

-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it." - Alan Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20091222/4d0cc8f1/attachment.html>