From owner-freebsd-hackers Thu Aug 5 21: 8: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 056F514E13 for ; Thu, 5 Aug 1999 21:07:57 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.3/8.8.7) with ESMTP id AAA88490; Fri, 6 Aug 1999 00:07:35 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 6 Aug 1999 00:07:35 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: John Polstra Cc: hackers@FreeBSD.org Subject: Re: NSS Project In-Reply-To: <199908060357.UAA08168@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 5 Aug 1999, John Polstra wrote: > In article , > Brian F. Feldman 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