Re: [Gcl-devel] New user question - more explicit information

[Camm Maguire]

Greetings!

kraehe <address@hidden> writes:

> Moin Jordan Rosenthal,
> 
> > 1) There are a bunch of configure options to get dynamic loading of 
> > compiled files (e.g., static bfd, local bfd, dynamic bfd, dlopen, etc). 
> >  Which is the preferred method?  Currently, I am using the dynamic bfd 
> > (i.e., the shared bfd libraries on my system).  Also, how does the 
> > gcl-elf-loader fit into the picture?
> 
>   BFD was only able to dynamicaly link objects, that had been written
>   to fit GCL, e.g. by (compile-file "somefile.lsp") and unable to load
>   and resolve external libraries. So extensions like X11 and OpenGL
>   needed a large GCL with a large wrapper, to bind any X11 and OpenGL
>   function.
> 
>   the elf-loader started as an experiment to reduce the size of
>   wrapper libraries for X11 and OpenGL. The idea was to bfd load
>   a wrapper that is able to access a dynamic link library and just
>   picking those functions from the library the application needs.
> 
>   So you only need to staticaly link one library 
>      (compiler::link '("elf-loader.o") "gclelf" nil "-ldl")
>   to access any library you want by dynamicaly bfd loading
>   your wrapper.
> 

While I need to study this wonderful work a bit more, my current
understanding is that it provides a transparent dlopen interface to
missing symbols on lisp object file load, and that perhaps there is
some mechanism to re-dlopen and reset the symbols on image reexecution
after image save via save-system.  Great!  It would be slightly
preferable in my opinion if we could do effectively the same loading
operations from native GCL sfasl code, but then instruct unexec to
write the necessary relocation records to the saved output images
which would enable the system dynamic linker to do the startup work on
image reexecution.  I'm going to try to take a stab at this at some
point, but If I get bogged down, I'll punt and use your great work.


> > 2) How do I use the compiler::link command?
> 
>   the compiler::link command will create a new GCL binary, with staticaly
>   linked additional object files and libaries. This should work on any
>   system, regardless of dynamic bfd or elf loading.
> 
> > Perhaps if it is simpler, we could work with a toy problem.  Let's say I 
> > have an external shared library...maybe the BLAS numerical library or 
> > the libxml2 library on Linux.  How do I create an image that let's me 
> > link to all the symbol's in these (shared) libraries from a clines 
> > construct later on?
> 
>   both certainly are'nt toy problems - a libxml2 wrapper would run
>   into the problem of UTF2ISO conversion, while BLAS might offer
>   other can of worms, i'm not aware of, but I think arrays of various
>   structure might need a lot of conversion. A wrapper for BLAS might
>   look like elf-test.lsp, so you first have elf::use-lib to tell
>   the system about the dynamic libariers your wrapper needs, next
>   a few functions like call_d1d with entrys like call-d1d, who
>   receive a pointer of the real library function to call. This
>   pointer is resolved by the later defun wrappers, calling
>   elf::usr-sym to pick the symbol from hash or to resolve it
>   with libdl.

Another wish list item for 2.7.0 or later is a little C header parser
to attempt to automate the type of defentries I posted earlier.  I
have a crude start, but not more time at present.  Volunteers for any
of this work most appreciated!

Take care,


> 
> ciao,Michael
> -- 
>   mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.29'UNZ+1'
>   http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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