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>
next in thread | previous in thread | raw e-mail | index | archive | help
--a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > > 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 sy= mbols > > > in the libraries. But once symbols start getting referenced by even = one > > > utility, such hacks are harder to manage. > >=20 > > Since nothing else in libc uses uuids, a static link will not be > > contaminated with them - i.e. statically linked binaries will be the sa= me > > size as before. >=20 > 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. >=20 > 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. >=20 crunchgen(1) + static linking gives best results. Cheers, --=20 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 --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9wlKBUkv4P6juNwoRAh0pAJ4r5xaO9tZYSVD8+0I81mBowtnkaACgiWfi +APIOGeqgeWa6cmpr08g+5M= =URFe -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021101100801.GA36739>