From owner-cvs-all Wed Oct 30 11:59: 1 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 7EA7137B401 for ; Wed, 30 Oct 2002 11:58:59 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 961F543E6E for ; Wed, 30 Oct 2002 11:58:57 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 91483 invoked by uid 1000); 30 Oct 2002 19:58:58 -0000 Date: Wed, 30 Oct 2002 11:58:58 -0800 (PST) From: Nate Lawson To: Doug Rabson Cc: 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 In-Reply-To: <20021030183926.M23855-100000@herring.nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message