Re: consistency in glibc add-on directory names?

["Robert P. J. Day" <rpjday at mindspring dot com>]

On Sun, 2 Oct 2005, Roland McGrath wrote:

> I'm not sure anyone has really used the ports tarball with 2.3 in
> fact. The only usable things in the ports 2.3 branch is the am33
> port, and I'd bet Alex just built it from cvs checkouts.  For the
> 2.3 branch, I am unlikely to change the main tree's makefiles.  So
> if anything changes, it will be the ports tarball to match the
> others.
>
> Before the 2.4 release, I mean to fix the magic so that add-on
> directories need not be unpacked directly under the main source
> tree.  Then it will make sense to switch uniformly to the usual
> convention for subdir names in tarballs.

just to put this in context, i was trying to summarize the current
state of glibc add-ons for "crosstool," a utility for building a
cross-compiler automatically (www.kegel.com/crosstool).

as i read it from perusing the archives and a couple of web pages, if
one is using the latest GNU packages (gcc-4.0.2, glibc-2.3.5, etc.),
then the only realistic options for add-ons seem to be:

  nptl		(favoured over linuxthreads)
  libidn

older "add-ons" (crypt, localedata) are now part of glibc itself, as
is nptl, while libidn still has to be downloaded separately.

  is that about the size of things these days?  other than nptl and
perhaps libidn, are there other add-ons that should be taken into
account?  thanks.

rday