Date: Wed, 02 Sep 1998 08:45:46 -0700 From: John Polstra <jdp@polstra.com> To: Mike Smith <mike@smith.net.au> Cc: current@FreeBSD.ORG Subject: Re: E-day problems: rtld-elf dlsym() broken? Message-ID: <199809021545.IAA22605@austin.polstra.com> In-Reply-To: Your message of "Tue, 01 Sep 1998 21:46:29 -0000." <199809012146.VAA00555@word.smith.net.au>
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? 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? > 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. > 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. ;-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth 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?199809021545.IAA22605>