Date: Mon, 20 Jan 1997 12:04:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: mark@grondar.za, peter@FreeBSD.org, current@FreeBSD.org Subject: Re: Static binaries and dlopen(3) with a new crypt(3) lib. Message-ID: <199701201904.MAA15840@phaeton.artisoft.com> In-Reply-To: <199701200534.VAA25350@austin.polstra.com> from "John Polstra" at Jan 19, 97 09:34:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The change Peter made was that dlopen() and related functions no > longer come up undefined under static linking. But they're just > stubs, and they always return an error. > > It's hard to support dlopen() under static linking, because the > dynamic linker isn't even present in the address space. It's not > impossible, just nontrivial. I've been meaning to look into it > for a while. Maybe this will get me moving. For ELF, if you are planning to do this, I believe the large gap prior to the mapping location of the user code (the base to which it is linked) was intentioanlly left there so that the image loader could map the ld.so into the process address space. Effectively, this means that other than a "constructor" style data reference, ld.so should be usable, demand-paged, in all address spaces, and the crt0.o should be the same for dynamic vs. static linking (assuming the construction of library interfaces takes place in a linker set in the C case as well as the C++ case). In general, this means adding the symbol references for dynamic relocation of dlopen, et. al., as part of the crt0.o ... effectively, always "dynamic linking" them into the process address space. We can discuss this in detail offline, if what I've said isn't clear (I suspect it is, since you're a known "compiler-head" 8-)). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701201904.MAA15840>