[Axiom-developer] C library support [ was Re: BLAS and GCL ]

[Camm Maguire]

Greetings!  This topic triggered an old idea which should be a major
GCL feature if it would be workable.  We should be able to write a
function which would take a library name and a C header file name as
arguments and create a new GCL image with the library linked in and
all its exported functions accessible via lisp wrappers in a new
package of the same name as the library.

In more detail:

1) read the piped output of 'nm' or 'nm --dynamic' on the library and
   collect the exported symbols

2) make a readtable which can parse the header file to read the
   prototypes.  Paul do you know of such a parser already available?

2.5) make a package with the same name as the library

3) translate the information in 2) directly into a defentry line

4) proclaim the function, write an compiler::inline entry to optimize
   the call.

5) export the symbols in the new package

6) (compiler::link (list "defentries.o") "new_image" "package_maker.lisp"
   "-lfoo -lbar")


For the standard C argument types, this should work with no further
effort.  The problem is that structure arguments, double pointers
(e.g. **), etc. will need new 'object_to_...' utilities in cmpaux.c,
care should be taken with external functions which may call malloc,
and defstruct calls would likely need to be constructed for each
typedef struct to make many functions usable.

Beyond this I just wanted to repeat the outstanding linker limitation
and cc Aurelien in case he might have ideas -- our internal linker is
static.  Would it be possible to detect a symbol which could not be
statically relocated, but could nonetheless be found with dlsym in the
currently used shared libs, use that address for the current session,
and alter the dynamic linker table of the running executable to mark
this symbol for treatment by ld.so on subsequent execution after an
unexec/save-system? 

The biggest complaint about lisp is the (lack of) library support, and
the idea of reimplementing everything in lisp appears to me to be a
definite non-starter.  Were such a modular approach to external C libs
attainable, one could dispense with separate support for xgcl, pargcl,
etc. and greatly simplify future maintenance.

Take care,


-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah