Date: Fri, 1 Nov 2002 12:08:01 +0200 From: Ruslan Ermilov <ru@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: Doug Rabson <dfr@nlsystems.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc Makefile.inc src/lib/libc/uuid Makefile.inc uuid.3 uuid.h uuid_compare.c uuid_create.c uuid_create_nil.c uuid_equal.c uuid_from_string.c uuid_hash.c Message-ID: <20021101100801.GA36739@sunbay.com> In-Reply-To: <Pine.BSF.4.21.0210301117400.91026-100000@root.org> References: <20021030183926.M23855-100000@herring.nlsystems.com> <Pine.BSF.4.21.0210301117400.91026-100000@root.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Wed, Oct 30, 2002 at 11:58:58AM -0800, Nate Lawson wrote: > On Wed, 30 Oct 2002, Doug Rabson wrote: > > On Wed, 30 Oct 2002, Nate Lawson wrote: > > > > > On Wed, 30 Oct 2002, Doug Rabson wrote: > > > > On Tue, 29 Oct 2002, Nate Lawson wrote: > > > > > > > > > Why is this going into libc and not something like libdce? > > > > > > > > I don't think anyone is planning to implement DCE. Decent unique > > > > identifiers are useful far beyond DCE. I use them for a portable M$ COM > > > > compatible system, the ia64 architecture uses them for many purposes > > > > including its disk partitioning system. > > > > > > > > -- > > > > Doug Rabson Mail: dfr@nlsystems.com > > > > > > Thanks, that's a useful explanation. I do a lot of work on embedded > > > systems and the size of libc is a concern (especially when using Linux > > > glibc). I'm not eager for FreeBSD's libs to grow. Sure there are > > > workarounds, like the shell script that extracts a list of all extern > > > symbols in your executables and then uniqs that out of the list of symbols > > > in the libraries. But once symbols start getting referenced by even one > > > utility, such hacks are harder to manage. > > > > Since nothing else in libc uses uuids, a static link will not be > > contaminated with them - i.e. statically linked binaries will be the same > > size as before. > > Most systems I've built use dynamic binaries to save on storage (flash) > but then we go and strip out unused, unreferenced portions of libc (i.e. > rpc). But once system binaries begin referencing a symbol, the utility > has to be hacked to remove that option. I can't point to any one function > that causes a lot of bloat this way but it is more the slow, inexorable > growth of functions that are -nearly- the same as each other. > > In brief: if every program had its own private strcpy, you devolve to the > statically linked case where you have (N - 1) * sizeof strcpy space > wasted. If every program uses one of two slightly different functions but > there are N subsystems that offer two slightly different functions > (strcpy/stpcpy/strlcpy, getopt/getopt_long), you're back to the same > problem except the bloat shows up in libc, not the programs. > crunchgen(1) + static linking gives best results. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9wlKBUkv4P6juNwoRAh0pAJ4r5xaO9tZYSVD8+0I81mBowtnkaACgiWfi +APIOGeqgeWa6cmpr08g+5M= =URFe -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021101100801.GA36739>