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 ?

As I wrote above, not only our STk is broken, but also our CLISP port.
I haven't tested cmu-cl yet.

Tia, -Martin

(*) Ours is 3.99.something-maybe-2 ?, latest is 4.0.something-maybe-1 ?
I wanted to resolve this issue and package an update, during which I stumbled
over this problem. The STk manual, ages old, lists us (NetBSD) as one of
the (few) OS on which ffi calls into foreign language libs (like c-.so's)
works, okay, it's ages old, but I'd like to have that be true again :)