Date: Tue, 22 Aug 2000 10:30:51 -0600 (MDT) From: Nate Williams <nate@yogotech.com> To: Paul Richards <paul@originative.co.uk> Cc: Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl>, Ollivier Robert <roberto@eurocontrol.fr>, "FreeBSD Current Users' list" <freebsd-current@FreeBSD.ORG>, green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <200008221630.KAA23905@nomad.yogotech.com> In-Reply-To: <39A2A98E.EC1D33C4@originative.co.uk> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> <20000822175438.B76789@caerdonn.eurocontrol.fr> <20000822180037.B28016@lucifer.bart.nl> <39A2A98E.EC1D33C4@originative.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> Alternatively the sentiment just rose why we couldn't just collapse the > > >> crypt/hash functions of libcrypt into libc. > > >> > > >> It would make sense. > > > > > >It would make even make more sense to convince the other BSD to do the same > > >(haven't checked recently what they do) and do the merge. > > > > I very much agree. > > > > Would it be sensible for the regular cypherpunks to discuss this with > > the NetBSD and OpenBSD brothers? > > > > Otherwise I would be willing to open this discussion on the appropriate > > lists. > > Is there any current policy on what libc is? It certainly isn't "libc" > as required by C and hasn't been for almost ever but there needs to be > some rational to its existence otherwise why not fold everything into > libc and not bother with any other libraries! > > A growing libc makes static binaries grow NOT! Static linking *only* brings in those symbols necessary for the file. It doesn't matter where those files are, they are only brought in if necessary. > and makes it more difficult to > strip out unneeded functionality from a minimalist system install. This is true. > I'd been inclined to try and move things the other way and strip stuff > out of libc into separate libraries but that's obviously not in vogue > at the moment. For what it's worth, I'm in agreement. The 'kitchen sink' approach, although easy tends to make stuff hard to maintain, since you end up with namespace collisions, and you may end up with something you are not aware of that conflicts with routines you are using inside your program. (Think of the recent weak symbol discussion where the library is not using the correct 'global' symbol for read as an example.) > Why does crypt need to be in libc? Not even a significant fraction of > applications need crypt? Agreed. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008221630.KAA23905>