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>