Date: Wed, 02 Sep 1998 09:34:05 +0000 From: Mike Smith <mike@smith.net.au> To: John Polstra <jdp@polstra.com> Cc: Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG Subject: Re: E-day problems: rtld-elf dlsym() broken? Message-ID: <199809020934.JAA03734@word.smith.net.au> In-Reply-To: Your message of "Wed, 02 Sep 1998 08:45:46 MST." <199809021545.IAA22605@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809020934.JAA03734>