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