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