Subject: Re: ELF Lord / Documentation searched for fixing STk and other lisp interpreters :)
To: None <firstname.lastname@example.org>
From: Jachym Holecek <email@example.com>
Date: 06/16/2002 15:31:37
> Okay, the problem I'm experiencing, is that STk (*) [and I think
> common lisp, too] cannot resolve symbols libraries rely on which
> it attempts to load via its foreign-function-interface. It can
> resolve everything I hard-compile with rpath set to the various
> directories. But for example when I have libxyz.so in /usr/pkg/lib,
> don't have /usr/pkg/lib in the rpath section of STk, then I can
> load it directly by using the full path. But if xyz also needs stuff
> from aaa.so which is in /usr/pkg/lib, it won't work, because
> that path isn't in the search section of the interpreter.
> Now my question to you guys, Could you please drop me a pointer to
> the right documentation on how to extend the search path section
> of the current process, or help me to solve the task by other
> means ?
If I'm no missing something, the following should help:
setenv LD_LIBRARY_PATH /usr/pkg/lib:LD_LIBRARY_PATH
See ld.elf_so(1) and/or ld.aout_so(1) for more information.
> As I wrote above, not only our STk is broken, but also our CLISP port.
> I haven't tested cmu-cl yet.
Well, they're not really broken ;-). There's no reason they should have
their rpath pointed to /usr/pkg/lib or whatever if they don't directly
depend on libraries found there.