Date: Wed, 6 Nov 2002 02:06:09 +0600 From: Max Khon <fjoe@iclub.nsu.ru> To: Jake Burkholder <jake@locore.ca> Cc: current@freebsd.org Subject: Re: libc size Message-ID: <20021106020609.A76730@iclub.nsu.ru> In-Reply-To: <20021106002050.A72989@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Wed, Nov 06, 2002 at 12:20:50AM %2B0600 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021106020609.A76730>