Date: Sat, 16 Nov 2002 17:43:31 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: dillon@apollo.backplane.com Cc: bright@mu.org, nate@root.org, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <20021116.174331.28768088.imp@bsdimp.com> In-Reply-To: <200211152017.gAFKHbFS044142@apollo.backplane.com> References: <200211151925.gAFJPsgh037805@apollo.backplane.com> <20021115194347.GG50692@elvis.mu.org> <200211152017.gAFKHbFS044142@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200211152017.gAFKHbFS044142@apollo.backplane.com>
Matthew Dillon <dillon@apollo.backplane.com> writes:
: I think that should be a goal. I think something like this:
:
: USE_MINIC=YES Link against the mini-C library.
I don't like this so much, but not enough to object to it be allowed,
but not default. I don't see what it buys us in the dynamic case, but
if you sign up to support it long term I won't pitch a fit. It will
likely only save a hundred or two k in the dynamic case, but maybe
there are some folks that might be able to use that. My misgivings
are mostly based on there not being a clear target market for minic
and my experiences with making CF systems for the past 3 years... I
think that the whole minic issue is orthoginal to the dynamic linking
of sbin/bin issue.
: USE_SHARED_BIN=YES Link against a shared libc or mini-C rather
: then linking statically.
Apart from the naming that doesn't really match the rest of the tree,
I like the latter. I'm assuming that you'll do the second of these
right by installing all the libraries that are needed for /{,s}bin
onto /lib, hacking ld.so, and creating a /rescue program like peter
described, I'm all for it. If all you are doing is making them
shared, then we already have that (the NOSHARED=no option that has
worked since the 4.x days) and the option is of dubious value.
I personally thing that we should have a shared /{s,}bin in 5.0 and
that it should be the dafult and that it should work with / and /usr
being on different partitions. Preliminary indications are that we'd
save on the order of 25M-30M on /, which makes up for the additional
kernel modules we now install.
Warner
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?20021116.174331.28768088.imp>