Hello,

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

Regards,
	Jachym Holecek