From owner-freebsd-current Mon Jan 20 11:20:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA19584 for current-outgoing; Mon, 20 Jan 1997 11:20:47 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA19574; Mon, 20 Jan 1997 11:20:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA15840; Mon, 20 Jan 1997 12:04:54 -0700 From: Terry Lambert Message-Id: <199701201904.MAA15840@phaeton.artisoft.com> Subject: Re: Static binaries and dlopen(3) with a new crypt(3) lib. To: jdp@polstra.com (John Polstra) Date: Mon, 20 Jan 1997 12:04:54 -0700 (MST) Cc: mark@grondar.za, peter@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199701200534.VAA25350@austin.polstra.com> from "John Polstra" at Jan 19, 97 09:34:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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.