From owner-freebsd-current Mon Jan 20 12:41:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25475 for current-outgoing; Mon, 20 Jan 1997 12:41:35 -0800 (PST) Received: from po2.glue.umd.edu (root@po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA25466; Mon, 20 Jan 1997 12:41:21 -0800 (PST) Received: from ginger.eng.umd.edu (ginger.eng.umd.edu [129.2.103.20]) by po2.glue.umd.edu (8.8.3/8.7.3) with ESMTP id PAA04554; Mon, 20 Jan 1997 15:41:09 -0500 (EST) Received: from localhost (chuckr@localhost) by ginger.eng.umd.edu (8.8.3/8.7.3) with SMTP id PAA02041; Mon, 20 Jan 1997 15:41:09 -0500 (EST) X-Authentication-Warning: ginger.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 20 Jan 1997 15:41:08 -0500 (EST) From: Chuck Robey X-Sender: chuckr@ginger.eng.umd.edu To: Terry Lambert cc: John Polstra , mark@grondar.za, peter@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Static binaries and dlopen(3) with a new crypt(3) lib. In-Reply-To: <199701201904.MAA15840@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 20 Jan 1997, Terry Lambert wrote: > > 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-)). The main idea of statically linked stuff is to allow it to work in the absence of /usr. This sounds like it's getting close to breaking that, no? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------