From owner-cvs-all Fri Nov 1 2: 8:56 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 666DE37B401; Fri, 1 Nov 2002 02:08:54 -0800 (PST) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C794443E42; Fri, 1 Nov 2002 02:08:48 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id gA1A81P38668; Fri, 1 Nov 2002 12:08:01 +0200 (EET) (envelope-from ru) Date: Fri, 1 Nov 2002 12:08:01 +0200 From: Ruslan Ermilov To: Nate Lawson Cc: Doug Rabson , 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> References: <20021030183926.M23855-100000@herring.nlsystems.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --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