>>>>> "Thomas" == Thomas Fischbacher <········@hphalle5a.informatik.tu-muenchen.de> writes:
Thomas> Question concerning CMU CL's alien interface (Linux x86):
Thomas> When I try to compile lisp source file (using CMU CL), say "test.lisp",
Thomas> which uses some alien functions from a C library, let's say "test.so",
Thomas> everything works as it ought to. But if I give my library file a
Thomas> different name, say "bunch-of-c-functions-for-lisp.so", then I can't
Thomas> do a (compile-file "test.lisp"). :-( Is it possible to make it work
Thomas> with different names for the .o / .so library and lisp source?
I don't quite understand the question. Can you give a more detailed
example?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> Thomas> everything works as it ought to. But if I give my library file a
> Thomas> different name, say "bunch-of-c-functions-for-lisp.so", then I can't
> Thomas> do a (compile-file "test.lisp"). :-( Is it possible to make it work
> Thomas> with different names for the .o / .so library and lisp source?
>
> I don't quite understand the question. Can you give a more detailed
> example?
The problem is: I've been writing a quite useful package containing
lots of macros which make it possible to interface C functions from
libraries like, say, "libOpenGL.so" efficiently in a uniform way from
within both Allegro CL and CMU CL (Linux x86, btw). Everything works
just fine by now, but one problem remains: my CMU CL refuses to
COMPILE-FILE Lisp Code which interfaces functions from a C library if
the name of the .so library is not the same as the name of the Lisp
.lisp source file. (Up to extension, of course.) CMU CL tells me that it
cannot find some symbols. (Loading the .so file into CMU CL before
compiling has no effect, either.)
So, whenever I want to COMPILE-FILE a bunch of Lisp source files which
interface functions from the same C library, I'm stuck. Of course, I
could do some "ln -s" or "ld -shared --whole-archive" tricks, but
that's extremely ugly. Is there a better way to do it?
--
regards, (o_
Thomas Fischbacher - ··@another.gun.de //\
········@informatik.tu-muenchen.de V_/_
>>>>> "Thomas" == Thomas Fischbacher <········@hphalle6c.informatik.tu-muenchen.de> writes:
Thomas> The problem is: I've been writing a quite useful package containing
Thomas> lots of macros which make it possible to interface C functions from
Thomas> libraries like, say, "libOpenGL.so" efficiently in a uniform way from
Thomas> within both Allegro CL and CMU CL (Linux x86, btw). Everything works
Will you make this available (the macros themselves and the OpenGL
interface)? Sounds like a really nice package!
Thomas> just fine by now, but one problem remains: my CMU CL refuses to
Thomas> COMPILE-FILE Lisp Code which interfaces functions from a C library if
Thomas> the name of the .so library is not the same as the name of the Lisp
Thomas> .lisp source file. (Up to extension, of course.) CMU CL tells me that it
Thomas> cannot find some symbols. (Loading the .so file into CMU CL before
Thomas> compiling has no effect, either.)
I've done compile-file on lisp code that used functions from another
library with a different name. I had to do a load-foreign before
compiling though, but that seems not to work for you.
I do something like this. Load up the libraries first:
(load-foreign "matlisp.o"
:libraries '(
"-R/usr/lib"
"-L/usr/lib"
"-R/apps/public/solaris2.5/lib"
"-L/apps/public/solaris2.5/lib"
"-llapackz"
"-llapackd"
"-lblasz"
"-lblasd"
"-L/apps/lang/fortran/v3.0.1/SUNWspro/SC3.0.1/lib/"
"-lM77"
"-lF77"
"-lsunmath"
"-lm"
"-lc"))
)
(In this case matlisp.o contains a dummy function that is never
called. I just need access to the stuff in the shared libs.)
Having done this, I can compile any lisp file that references the
functions in the LAPACK shared libs.
Ray