From owner-freebsd-current Mon Jan 20 13:11:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA28075 for current-outgoing; Mon, 20 Jan 1997 13:11:45 -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 NAA28063; Mon, 20 Jan 1997 13:11:36 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16242; Mon, 20 Jan 1997 13:55:24 -0700 From: Terry Lambert Message-Id: <199701202055.NAA16242@phaeton.artisoft.com> Subject: Re: Static binaries and dlopen(3) with a new crypt(3) lib. To: chuckr@glue.umd.edu (Chuck Robey) Date: Mon, 20 Jan 1997 13:55:24 -0700 (MST) Cc: terry@lambert.org, jdp@polstra.com, mark@grondar.za, peter@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Jan 20, 97 03:41:08 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 > > 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? No. If the symbols are only resolved on reference, then they can be present and unresolved without impacting operation. If a reference occurs to the symbol and the backing page is not mapped because the object was not there, *then* a failure can occur. How well does dlopen() work in static binaries now? ...not at all. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.