Subject: [clisp-list] references to shared libraries from within shared objects?

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Thu Apr 4 00:11:23 2002

Hi,

Could somebody please shed light on the ability under UNIX to load a shared object which would require some new library to be linked against the whole Lisp binary in order to locate symbols referenced by that object?

E.g. suppose my executable doesn't use sockets, can I dlopen("mysock.so") which provides a layer around sockets but then obviously requires the system socket lib to be linked against my binary (e.g. libnsl or some such)?

It seems not possible according to the following text, since my executable initially was not linked against tons of libraries (e.g. libX, libsocket, libSSL, libLDAP, libKerberos etc.):

Dynamic Shared Objects (for Apache):
http://httpd.apache.org/docs/dso.html
"Or in other words, modules compiled as DSO files are restricted to
only use symbols from the Apache core, from the C library (libc) and
all other dynamic or static libraries used by the Apache core, or from
static library archives (libfoo.a) containing position independent
code. The only chances to use other code is to either make sure the
Apache core itself already contains a reference to it, loading the
code yourself via dlopen() or enabling the SHARED_CHAIN rule while
building Apache when your platform supports linking DSO files against
DSO libraries."

OTOH using CMUCL on SunOS and Solaris, we once did:
;/* Preprocessed Lisp file */
    (load-foreign (list "/cmp_ld/ipc_lisp.o")
      :libraries  (list "/cmp_ld/libknipcms.a")
#ifdef __GNUC__
			(concatenate (quote string) root "/cmp_ld/libgcc.a")
#endif
                        "-lc"))
but that was in foo.o + lib.a time, vs now programmers seem to favour foo.so + lib.so.1.x

The typical dlopen() interface doesn't feature an extra :libraries argument.

Thanks for your help,
	Jörg Höhle.