Date: Tue, 01 Sep 1998 21:46:29 +0000 From: Mike Smith <mike@smith.net.au> To: John Polstra <jdp@polstra.com> Cc: Mike Smith <mike@smith.net.au>, chuckr@glue.umd.edu, current@FreeBSD.ORG Subject: Re: E-day problems: rtld-elf dlsym() broken? Message-ID: <199809012146.VAA00555@word.smith.net.au> In-Reply-To: Your message of "Tue, 01 Sep 1998 21:35:33 MST." <199809020435.VAA18125@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Given that the goal here seems to be able to use dlopen to load > > modules into an otherwise self-contained executable, would it be > > more correct to suggest that the executable should be linked shared, > > but against a static copy of the C library? > > I don't think that will work either, in general. The trouble is, > when you link against a static library, only the modules actually > used by the program are linked in. The other ones don't appear > in the linked program at all. 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. > You might be able to work around it by linking the executable with > "--whole-archive" to the linker, or some such nonsense. But that > would make your executable very large. That would defeat the purpose of the exercise, certainly. > > If this is correct, what's the "polite" way to explicitly reference > > libc? > > If you dlopen "libc.so.3" (a name without any slash characters) then > the dynamic linker will search in all the usual places. That's the > politest way I can think of. 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 Such a program wouldn't require a shared libc image to run, but would be able to use dlopen() to load plugins (subject to the implications above). Consider the implications of this eg. in the context of PAM. -- \\ 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?199809012146.VAA00555>