Hello,
Can someone point me to resources explaining how to interface Lisp and
C++? In particular, I am attempting to interface cmucl with the lti
image processing lib (see
http://ltilib.sourceforge.net/doc/homepage/index.shtml). I am using
uffi 1.3.6 and cmucl 18e on redhat linux 9. So far:
1) I am able to run the examples shipped with uffi.
2) After a sight modification (declaring the functions to be extern
"C") I am able to run the uffi examples when compiled in C++ mode.
3) If I include a header from the lti lib and repeat the experiment,
I get the following error:
Error in function SYSTEM::LOAD-OBJECT-FILE:
Can't open object "/home/swd/projs/alien/c-test-fns.so": NIL
I looked at the cmucl source for load-object-file and it calls dlopen
and dlerror. I wrote a C program to try to use dlopen to load the
library and dlerror to find the error. dlerror returned:
undefined symbol: __gxx_personality_v0. [Note 1]
This symbol is defined in libstd++.so. In my C program if I load libstd++.so
with dlopen, and then load c-test-fns.so then dlopen succeeds.
4) In the lisp program, I can load libstd++.so without error. However, after I
load this, if I load c-test-fns.so I get the following error:
Arithmetic error FLOATING-POINT-INVALID-OPERATION signalled.
[Condition of type FLOATING-POINT-INVALID-OPERATION]
Restarts:
0: [ABORT] Return to Slime toplevel.
1: [ABORT] Return to Top-Level.
Backtrace:
0: (X86:SIGFPE-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFDE18))
1: ("Foreign function call land")
2: ("Foreign function call land")
3: ("Foreign function call land")
4: ("Foreign function call land")
5: ("Foreign function call land")
6: ("Foreign function call land")
7: ("Foreign function call land")
8: ("Foreign function call land")
9: ("Foreign function call land")
10: ("Foreign function call land")
11: ("Foreign function call land")
12: ("Foreign function call land")
13: ("Foreign function call land")
14: ("Foreign function call land")
15: ("Foreign function call land")
16: ("Foreign function call land")
17: (SYSTEM::DLOPEN "/home/swd/projs/alien/c-test-fns.so" 258)
18: (SYSTEM::LOAD-OBJECT-FILE "/home/swd/projs/alien/c-test-fns.so")
I am a bit stuck here. Any ideas on how to fix this problems or general information
on interfacing lisp and C++ would be greatly appreciated.
Thanks,
-Scott
[Note 1] I think system::load-object-file should have also printed
this "undefined symbol" message because it also calls dlerror. But in
lisp dlerror seems to return NIL. I don't know why.
PS.
I also ran into a minor problem with uffi. If I start lisp (slime in
xemacs) in the same directory as the library I want to load then
uffi:find-foreign-library returns a path like #p"foo.so" - which
uffi:load-foreign-library can not seem to use. However, if I start
lisp in another directory, then it returns #p"/some/path/foo.so" which
works. This is easy to work around, but I thought I would mention it.
>>>>> "sd" == Scott Determan <········@world.std.com> writes:
For CMUCL-specific questions, you might be better off on the CMUCL
mailing lists. See <URL:http://www.cons.org/cmucl/support.html>.
sd> I looked at the cmucl source for load-object-file and it calls dlopen
sd> and dlerror. I wrote a C program to try to use dlopen to load the
sd> library and dlerror to find the error. dlerror returned:
sd> undefined symbol: __gxx_personality_v0.
sd>
sd> This symbol is defined in libstd++.so. In my C program if I load libstd++.so
sd> with dlopen, and then load c-test-fns.so then dlopen succeeds.
your c-test-fns.so library isn't built correctly; it should have a
dynamic dependency on libstd++.so. You can check the dependencies of a
shared library as you would for an executable, by using ldd. If the
dependencies are registered, dlopen() will load the dependent
libraries first and things should work.
Alternatively, you can use CMUCL's via-ld loading, as per
(ext:load-foreign "c-test-fns.so" :libraries '("-lstdc++"))
sd> In the lisp program, I can load libstd++.so without error. However, after I
sd> load this, if I load c-test-fns.so I get the following error:
sd> Arithmetic error FLOATING-POINT-INVALID-OPERATION signalled.
that doesn't sound very promising; the library has probably corrupted
your lisp heap. It may have mapped memory regions that CMUCL uses; you
can check whether there is any overlap between the memory ranges used
by your C program that loads the library and those of CMUCL
(information available from /proc/<pid>/maps under Linux).
If this is the case you'll need to rebuild CMUCL with a different
memory map that leaves more space for C libraries, which isn't a
trivial undertaking.
sd> [Note 1] I think system::load-object-file should have also printed
sd> this "undefined symbol" message because it also calls dlerror. But in
sd> lisp dlerror seems to return NIL. I don't know why.
I've noticed that, and I don't know why it happens.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>