Re: [CLSQL-Devel] How CLSQL finds and loads foreign libraries

Edi Weitz <[email protected]>
Newsgroups gmane.lisp.uffi.devel,gmane.lisp.clsql.devel
Message-ID <[email protected]>
On Wed, 8 Jun 2005 12:06:35 -0600, Kevin Rosenberg <kevin-HJRc7zDS/[email protected]> wrote:

> There's a problem with the UFFI change when loading a shared library
> pathname on AllegroCL and Linux. It involves the use of the
> TRUENAME. Here's an example:
>
> CL-USER(4): (load "/usr/lib/libmysqlclient.so")
> ;     Foreign loading /usr/lib/libmysqlclient.so.
> T
> CL-USER(5): (uffi:load-foreign-library #p"/usr/lib/libmysqlclient.so")
> ;     Loading /usr/lib/libmysqlclient.so.14.0.0
> Error: Attempt to take the value of the unbound variable
>        `ELF <binary garbage>...'.
>
> Your patch use TRUENAME which Allegro (and others) converts to the
> libmysqlclient.so symbolic link into the actual
> libmysqlclient.so.14.0.0 file name. Apparently, Allegro looks at the
> pathname type to determine if it is loading a shared library or a
> text file.

Hmm, OK, then maybe we can conditionalize the usage of TRUENAME to
Windows.  I first tested on Linux without TRUENAME and then on Windows
where I realized that without TRUENAME at least LispWorks treats names
with absolute paths like UNC names (or however they're called) and
loading CLSQL takes a lot longer.  So I introduced TRUENAME and when
testing on Linux again I might have skipped some platforms.

As I said, I think TRUENAME is only needed on Windows and Windows
doesn't have symbolic links, so conditionalizing this should be OK.

Cheers,
Edi.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.