Date: Wed, 30 Oct 2002 18:40:09 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Nate Lawson <nate@root.org> Cc: Marcel Moolenaar <marcel@freebsd.org>, <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: <20021030183926.M23855-100000@herring.nlsystems.com> In-Reply-To: <Pine.BSF.4.21.0210300958300.91026-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 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?20021030183926.M23855-100000>