On Mon, Dec 08, 2003 at 01:19:14AM -0500, William Conrad Halliburton wrote:
> Attempting to port a program from cmucl to sbcl. I was using a c++
> library and glue code but need cplus_demangle from libiberty.a.
> (load-foreign "/usr/lib/libiberty.a")
> (define-alien-routine "cplus_demangle" c-string (mangled c-string)
> (options integer))
> Worked fine from cmucl but 'unknown foreign symbol: "cplus_demangle"'
> from sbcl. Is there a problem with load-foreign? How do I go about
> checking the foreign function interface?
> sbcl-0.8.6.22 on linux.
LOAD-FOREIGN isn't really properly supported on SBCL, and there's an
on-again off-again low-level debate about what to do about it. We may
just punt it completely and replace it with LOAD-1-FOREIGN.
The way that I dealt with a lib.a file recently was to break it up
with "ar x", put it back together again with "ld -shared -o lib.so",
and then use LOAD-FOREIGN on the resulting lib.so. That might or might
not be sufficient for your needs.
The relevant bits of the Makefile that I used look more or less like
# not our job to build this file
ar x $(LIBFOO_A) $(FOOOBJS)
ld -shared -o $@ $(FOOOBJS)
William Harold Newman <william.newman@...>
In examining the tasks of software development versus software maintenance,
most of the tasks are the same -- except for the additional maintenance
task of "understanding the existing product". -- Robert L. Glass, _Facts
and Fallacies of Software Engineering_
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C