[cells-devel] Re: Problem Report: frgo/001/a0100: Cannot load C++ shared library

[Frank Goenninger]

Dear Support Team:

Here is some additional info about observations I made when trying to
fix the problem outlined below:

1. In some cases ACL fails to load shared libs when the path
   points to a symbolic link instead of a real file.
   
2. The error is related to the file identification behavior of 
   `load':

   * In case of correctly identifying the file as a foreign file
     the message appearing is 
     "; foreign loading ..."

   * In case of not correctly identifying the file as a foreign file
     the message is (consistently)
     "; loading ..."

   So I wanted to direct this into finding out how `load' identifies
   foreign files as such. Unfortunately, I wasn't able to find a lower
   level call that "really loads a foreign file" (assuming load is
   just the top layer and the interface to underlying machinery).

Any hints are appreciated. Thanks again.

Best regards,
   Frank Goenninger

On Tue, 2004-02-24 at 00:01, Frank Goenninger wrote:
> Dear Support Team @ Franz:
> 
> I am currently struggling to load a shared library using `load'.
> 
> I would appreciate your help in sorting this out. Thank you very much
> in advance!
> 
> I. DRIBBLE FILE
> 
> See attached dribble-bug file for a session transcript and system infos.
> 
> II. PROBLEM DESCRIPTION
> 
> Product:   ACL 6.2 Trial
> Plattform: Debian/Linux, Kernel 2.4.20, glibc3.3
> 
> I have a "homebrew" shared library that contains several C++ object
> files. When I try to load that shared library I consistently get the
> following error:
> 
> ;   Loading /home/frgo/projects/cello/ftgl-int/libftglint.so.1
> Error: Attempt to take the value of the unbound variable
>        ^?ELF^A^A^A^A^A^A ....
>   [condition type: UNBOUND-VARIABLE]
> 
> A first interpretation on my side was that the generated shared 
> library is somehow damaged in the format and `load' is unable to
> determine the right way to actually load it. So I wrote a short
> C program to test if I can load it using plain C methods. 
> 
> This succeeds - the functions used are dlopen, dlsym, and dlclose.
> 
> See section III. Example/Test of this email for the actual source
> code.
> 
> A second interpretation would be that the C++ shared library loads
> into different memory regions than a normal C shared library - 
> thereby destroying memory regions occupied by the AllegroCL image.
> But this is beyond my testing possibilities...
> 
> I checked carefully all documentation for AllegroCL 6.2 on your
> web site and also did some googling for relevant info - no luck...
> 
> III. Example/Test Source Code
> 
> Attachment "Makefile": a generated Makefile, to be called by `make'.
> Attachments "FTGLFromC.cpp", "main.cpp": source code files.
> Attachment "libftglint.so.1": The shared lib built from FTGLFromC.cpp
> and a futher, precompiled static library.
> Attachment "ftgl.lisp": The Lisp source file containing the code to
> load the shared libs.
> 
> Note: Loading plain C shared libs works as expected.
> 
> The Lisp source uses UFFI as a layer in between AllegroCL's own
> foreign function interface. For AllegroCL the call to 
> uffi:load-foreign-library  simply translates into a call to 
> load.
> 
> Of course I am ready to answer questions. You may reach me by phone:
> 
> +49 7123 932355
> 
> or by email. Just reply to this email.
> 
> THANKS AGAIN!
> 
> Best regards,
> 
>    Frank Gönninger
> 
> --
>   Frank Gönninger, DG1SBG
>   Bempflingen, Germany
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20040224/3725e595/attachment.sig>