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
>
>