From owner-freebsd-current Tue Nov 5 12: 7:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9076137B413 for ; Tue, 5 Nov 2002 12:07:25 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 390C643E6E for ; Tue, 5 Nov 2002 12:07:24 -0800 (PST) (envelope-from fjoe@iclub.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 1899yM-00070r-00; Wed, 06 Nov 2002 02:06:50 +0600 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 1899xx-0006sj-00; Wed, 06 Nov 2002 02:06:25 +0600 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.6/8.12.6) with ESMTP id gA5K6BFG077345; Wed, 6 Nov 2002 02:06:11 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.6/8.12.6/Submit) id gA5K69d7077344; Wed, 6 Nov 2002 02:06:09 +0600 (NS) Date: Wed, 6 Nov 2002 02:06:09 +0600 From: Max Khon To: Jake Burkholder Cc: current@freebsd.org Subject: Re: libc size Message-ID: <20021106020609.A76730@iclub.nsu.ru> References: <20021031220633.3acd0b53.flynn@energyhq.homeip.net> <3DC1AB26.5020708@acm.org> <20021103155858.3be6eda9.flynn@energyhq.homeip.net> <3DC6CB56.8090809@acm.org> <20021104215734.GA47193@dragon.nuxi.com> <20021105125454.A51180@iclub.nsu.ru> <20021105021823.T22677@locore.ca> <20021105132142.A52607@iclub.nsu.ru> <20021105120833.V22677@locore.ca> <20021106002050.A72989@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021106002050.A72989@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Wed, Nov 06, 2002 at 12:20:50AM +0600 X-Envelope-To: jake@locore.ca, current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi, there! On Wed, Nov 06, 2002 at 12:20:50AM +0600, Max Khon wrote: > The only way to save space in / and to be able to use nsswitch is > "make everyhting shared" exactly like NetBSD did a few weeks ago. > I saw a number of complaints about loosing an ability to repair system > if something goes wrong. I guess that people just haven't looked at what > NetBSD folks have done. Yes, they have a number of statically linked > programs in /rescue. Yes, they have created /lib. I was not 100% correct there. I know about a idea to use a daemon (for NSS) that listens on unix domain socket but that would not save space either because you had to have fallbacks in libc anyway (for case when this daemon is not running). > > -rwxr-xr-x 1 jake wheel 143177 Nov 5 11:57 hello > > > > This is more than twice as big as a normal static binary which just > > calls printf on my system. ~90K bloat just for dlopen. > > This is the price you pay for dlopen. This is how things are > in other systems that are capable of using dlopen in statically > linked executables. > > > I don't see that you've dealt with getting the linker to generate > > the tables that rtld needs; an _DYNAMIC section, a dynsym table, > > a dynstr table etc. These are needed in order to look up symbols in > > the statically linked binary itself. Getting the linker to do this is > > not overly difficult, we do it for the kernel, but it bloats the static > > binaries more. > > I do not have Solaris at hand but Linux is not capable of resolving > symbols refs in shared objects to main binary. I need to add (aside from what I told in previous letter) that requirement for libdl to build _DYNAMIC section means changes to binutils (because there is no information in statically linked executable which libdl can use to build such section). I think this is not the game anyone would like to play. By the way, space bloat is not that large: fjoe@husky:~$ls /bin /sbin | wc -l 132 fjoe@husky:~$ Some of that programs are hard-linked and some of them do not use getXXXbyYYY functions (or call other functions that use getXXXbyYYY, like user_from_uid). The "bloat" will be about 10M in worst case and this is quite appropriate before we switch to shared / Of course, there should be NO_NSS knob for libc for embedded environments. I do not consider my work as something that FreeBSD badly needs and do not insist on getting it right now as is (yes, it needs some polishing and maybe not everything works as expected, yes there are some obvious limitations in using dlopen from statically linked programs), but I think it removes some of limitations we currently have. Yet another example of stuff that (I think) we need to have in libc and which uses dlopen is Citrus Project (I18N Framework). /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message