From owner-freebsd-current Wed Sep 2 09:37:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19409 for freebsd-current-outgoing; Wed, 2 Sep 1998 09:37:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from word.smith.net.au (castles248.castles.com [208.214.165.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19404 for ; Wed, 2 Sep 1998 09:37:34 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id JAA03734; Wed, 2 Sep 1998 09:34:06 GMT (envelope-from mike@word.smith.net.au) Message-Id: <199809020934.JAA03734@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: John Polstra cc: Mike Smith , current@FreeBSD.ORG Subject: Re: E-day problems: rtld-elf dlsym() broken? In-reply-to: Your message of "Wed, 02 Sep 1998 08:45:46 MST." <199809021545.IAA22605@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Sep 1998 09:34:05 +0000 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > If you dlopen a shared object that needs some additional libc > > > functions, it won't be able to find them. > > > > That's OK, and under the circumstances we're talking about, not > > actually likely to be a serious problem. The principal candidate > > for this sort of activity is plugin modules, where you can generally > > supply a very strict API to the plugin. > > But can you strictly define in advance which library functions the > plug-in is allowed to call? That seems awfully risky. It would limit > the possible plug-ins to what you can anticipate on day 0. Doesn't > that defeat one of the main purposes of plug-ins, which is to allow > expansion of functionality in ways unanticipated at the outset? It depends on what the plugin does. For eg. the NAT plugin in PPP, or a Netscape plugin, or the plugin API I wrote for a signal processing application, the API is generally well-defined, and it's usually limited almost exclusively to functionality directly from the host executable. > What's the reason for not using dynamic linking? Is it space you're > trying to save, or do you just want everything to be in one file, or > is it something else? Primarily it's space considerations, but in the current scenario where libraries are in /usr/lib, anything that wants to run before /usr is mounted needs to be self-contained. > > I was actually referring to the process whereby you would create a > > dynamically-linked program which contained static copies of its imports > > from libc, ie. a more civlised version of: > > > > cc -nostdlib -o foobar foobar.o /usr/lib/libc.a > > Playing around with the existing ELF tools, I can't find any way to > make a dynamic executable without linking in at least one shared > library. I suppose the tools could be munged. Or, you could just > link in a special tiny shared library to force dynamic linking. But > as soon as you have a dynamically-linked program, then the program > requires ld-elf.so.1, which means it's not stand-alone any more. Is this because the tools decide there are no shared libraries and thus produce a static output? That's a little unfortunate I guess. > > Consider the implications of this eg. in the context of PAM. > > My view is that dynamic linking and shared libraries are good things > that should be used universally, except for the minimum set of > recovery tools (cp, mv, and so forth), and possibly a few other > programs where optimum performance is important. (-current readers, > please drop me from the cc list of the interminable religious argument > which will no doubt follow. I'll read all about it in the list. ;-) Mandating shared libraries would kill PicoBSD, and any related embedded systems. I think that would be Bad. I'll leave the religious gumpf out; practicalities are all I have time for. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message