Date: Wed, 30 Oct 2002 11:58:58 -0800 (PST) From: Nate Lawson <nate@root.org> To: Doug Rabson <dfr@nlsystems.com> 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 Message-ID: <Pine.BSF.4.21.0210301117400.91026-100000@root.org> In-Reply-To: <20021030183926.M23855-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210301117400.91026-100000>