Date: Fri, 6 Aug 1999 00:07:35 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: John Polstra <jdp@polstra.com> Cc: hackers@FreeBSD.org Subject: Re: NSS Project Message-ID: <Pine.BSF.4.10.9908052359530.87226-100000@janus.syracuse.net> In-Reply-To: <199908060357.UAA08168@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Aug 1999, John Polstra wrote:
> In article <Pine.BSF.4.10.9908052127030.86114-100000@janus.syracuse.net>,
> Brian F. Feldman <green@FreeBSD.ORG> wrote:
> >
> > Mind pointing me to the technical reason why (I'm sure you've explained
> > it before) we can't use the dl* calls in any way without linking
> > against ld-elf.so.1? I mean, have them in libc, for instance...
>
> The versions in libc are just stubs. Take a look at
> "src/lib/libc/gen/dlfcn.c". The implementations are in the dynamic
> linker.
Yes. I said "have them" as in "we could", not "we do have them in libc..."
>
> > One option I don't think anyone's brought up: why don't we _just_
> > have ld-elf.so.1 in the root, but not libraries? That way, we
> > don't bloat root excessively, but we can let people depend on
> > being able to build -static/-Bstatic binaries that make everything
> > static except the rtld? And modify gcc/ld to have static link with
> > the rtld, so we have the benefit of those calls, can have static
> > binaries still, and be able to depend on having an rtld (even for
> > single-user mode.)
>
> I think you have some misconceptions about how it all fits together.
> Executables aren't "linked with" the dynamic linker. It's a
> separate shared object that is loaded directly by the kernel. It
> gets control before the main executable gets control. Look at
> "src/sys/kern/imgact_elf.c" and at the dynamic linker.
I suppose I do have some misconceptions. I'll look at the "FreeBSD" ELF
image activator. I know how ld-elf gets control first, and calls .init
things, etc. But:
{"/usr/src/contrib/egcs"}$ grep -R ld-elf .
./gcc/config/alpha/freebsd.h: %{!dynamic-linker:-dynamic-linker /usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd.h: %{!dynamic-linker: -dynamic-linker /usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd-elf.h: %{!dynamic-linker:-dynamic-linker /usr/libexec/ld-elf.so.1}} \
What should that tell me exactly?
>
> Also, programs that are linked (at "ld" time) with dynamic libraries
> are different from programs that are linked with static libraries.
> I.e., "ld" does very different things in the two cases. You can't
> take a statically-linked program and suddenly decide to treat it as
> dynamically-linked at runtime. It's too late at that point.
Of course, but you can have a pseudo-static binary, one that only
needs ld-elf.so.1 but not libc, etc.
>
> Finally, shared "libraries" aren't really libraries at all in the
> traditional sense. They're monolithic whereas traditional archive
> libraries are made up of separate object files which are subsetted by
> the linker.
Mm-hmm. ld -Bshareable as opposed to ar rc.
>
> To really understand the issues I think it's necessary to read through
> the dynamic linker sources and understand what it's doing. There used
> to be books that described how it all worked (Prentice-Hall "System V
> Application Binary Interface"), but as far as I know they're out of
> print now.
I just think we're not seeing eye to eye.
>
> John
> --
> John Polstra jdp@polstra.com
> John D. Polstra & Co., Inc. Seattle, Washington USA
> "No matter how cynical I get, I just can't keep up." -- Nora Ephron
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908052359530.87226-100000>