Date: Mon, 7 Aug 2000 15:56:20 +0200 (CEST) From: Raymond Wiker <Raymond.Wiker@fast.no> To: "Daniel O'Connor" <darius@dons.net.au> Cc: Raymond Wiker <Raymond.Wiker@fast.no>, freebsd-hackers@freebsd.org Subject: RE: dlopen() and friends from a statically-linked binary? Message-ID: <14734.49156.249444.881713@raw.gren.fast.no> In-Reply-To: <XFMail.000722015322.darius@dons.net.au> References: <14711.10742.914512.819982@raw.gren.fast.no> <XFMail.000722015322.darius@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor writes: > > On 20-Jul-00 Raymond Wiker wrote: > > Is it possible, at all, to use dlopen etc from a > > statically-linked executable? My experiments with FreeBSD-4.0 (see > > below) indicate that it's not possible. > > You can't do it from a statically linked binary, however you can > create a dynamic executable with no external unresolved > references.. I forget how though :-/ OK... I'll take a look at this. Thanks to everyone who responded. > > > The reason that I'd like this to work is that SBCL (a Common > > Lisp implementation, see http://sbcl.sourceforge.net) needs the > > addresses of certain library symbols (e.g, errno) when building the > > initial lisp image. This seems to require static linking. On the other > > hand, SBCL is severely handicapped if it cannot subsequently use > > dlopen() to load foreign code into the running lisp system. > > Well, I don't see why it would need static linking for that.. When > the binary runs the libraries it uses will get loaded, and then it > can use dlsym() to get the addresses it needs.. (ie what I am > saying is I don't understand your explanation :) A running SBCL system includes a runtime substrate written in C, along with Lisp code compiled into native code or byte-code. The C runtime calls a top-level function in the Lisp system at startup; this call does not return until the top-level Lisp function exits. The top-level Lisp function calls into the C substrate for various low-level services, including garbage-collecting of Lisp objects. This implies a circular dependency: the C runtime must have the address of the top-level Lisp function, while the Lisp code needs the addresses of various code and data in the C runtime. In SBCL this is solved in the bootstrapping process, by a function that patches up the Lisp code with the addresses from the C code. This cannot be done at startup, as the Lisp object format differs from the conventional formats (a.out or ELF). At the moment, my options seem to be: 1) find a way of compiling the C runtime so that there are no unresolved externals, while still producing a dynamic executable. 2) identify a small set of symbols from libc.so, and encapsulate them (possibly using dlsym("foo", RTLD_NEXT)?) 3) modify SBCL so that the patchup is done at startup time, instead of at compilation time. Of these, 1) is probably the least work, 2) is slightly more work and inelegant, and 3) is the most work but carries a few other benefits (notably, it reduces the Lisp -> C dependency). //Raymond. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14734.49156.249444.881713>