Re: building glibc-2.3.2 on 164SX

[Kelledin <kelledin+AXP skarpsey dyndns org>]

On Tuesday 11 November 2003 11:21 pm, Rajiv Prasad wrote:
> Hi folks:
>
> I'm attempting to build glibc-2.3.2 on my RH 7.2 system (a
> 164SX).  I read the FAQ and build instructions, and the
> section about add-ons are not quite clear to me.  Questions:
>
> 1. what are add-ons, and why are they a separate download?

AFAIK, for glibc-2.3.2, the only "add-on" that's in a second 
package is LinuxThreads.  The rest actually come with the 
baseline glibc source code.

glibc-crypt used to be separate in 2.1.3 due to export 
restrictions on strong encryption software.  That's changed now, 
and crypt is part of the baseline sources.  I don't know for 
certain, but I think linuxthreads is separate because it's 
Linux-specific (glibc is designed to compile and work on more 
than just Linux).

(Well, there's nss_db and nss_lwres, but I don't know how current 
or useful those are, or if they can be built separate from the 
glibc source tree.  I personally have never had a need for 
them.)

> 2. if I "run" /lib/libc.so.6.1, I get this:
>
> GNU C Library stable release version 2.2.4, by Roland McGrath
> et al. Copyright (C) 1992-1999, 2000, 2001 Free Software
> Foundation, Inc. This is free software; see the source for
> copying conditions. There is NO warranty; not even for
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> Compiled by GNU CC version 2.96 20000731 (Red Hat Linux 7.2
> 2.96-112.7.2). Compiled on a Linux 2.4.9-9 system on
> 2003-03-21.
> Available extensions:
>     GNU libio by Per Bothner
>     crypt add-on version 2.1 by Michael Glad and others
>     The C stubs add-on version 2.1.2.
>     linuxthreads-0.9 by Xavier Leroy
>     BIND-8.2.3-T5B
>     NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
>     Glibc-2.0 compatibility add-on by Cristian Gafton
>     libthread_db work sponsored by Alpha Processor Inc
> Report bugs using the `glibcbug' script to <bugs gnu org>.

I have all of the above, except for the C stubs add-on and the 
Glibc-2.0 compatibility add-on.  My glibc-2.3.2 is built from 
basically stock sources plus the linuxthreads add-on.  For 
reference, my libc.so.6.1 spits out the following:

GNU C Library stable release version 2.3.2, by Roland McGrath et 
al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR 
A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.2.3.
Compiled on a Linux 2.4.21-3 system on 2003-10-14.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bugs gnu org>.

> So I gather that the glibc I have right now has these add-on
> compiled in: libio, crypt, C stubs, linuxthreads, BIND,
> NIS(YP)/NIS+ NSS. Glibc-2.0 compatibility, and libthread_db. 
> I should compile these in the new glibc too, right?

Probably a good idea.  I don't know how to get the C stubs add-on 
enabled (I didn't know it existed until now and actually lived 
just fine without it).  glibc-2.0 compatibility can probably be 
enabled by a certain switch to ./configure, although I don't 
recall exactly what switch.  It enables some glibc cruft that's 
only really useful for very old closed-source precompiled apps 
that were built against glibc-2.0.x.

> 3. where do I get these add-ons?  I found linuxthreads in the
> same download directory as the glibc, but not the rest of
> them.

Most are included in the baseline glibc source tree and are 
typically enabled by default.

> 4. I'm running kernel 2.4.22 (vanilla kernel.org sources
> compiled for 164SX using gcc-2.96).  The glibc build
> instructions say I should grab the latest kernel headers and
> put them in <linux/*.h> and <asm/*.h> in the top-level glibc
> source directory.  I have the kernel headers in
> <.../linux-2.4.22/include/linux/*.h> and
> <.../linux-2.4.22/include/asm/*.h>. If I just make symbolic
> links to these locations from the top-level glibc sirectory,
> would that work?

It's better to copy the kernel headers, rather than make symlinks 
to directories whose contents may change with a new kernel 
version.  When you compile glibc against a set of kernel 
headers, you ought to keep those kernel headers tied to that 
compile of glibc.

> 5. the build instructions tell me to get the *latest* kernel
> headers. Should I get 2.6 headers, or are the headers from
> 2.4.22 okay?

Stock 2.4.22 headers are generally OK, unless you want NPTL (New 
POSIX Threading Library).  glibc developers recommend using a 
late 2.5 or 2.6pre kernel for NPTL.  Note, RedHat 9.0 used a 
heavily hacked 2.4 kernel containing a backport of NPTL, so 
that's another option for enabling NPTL.

While RedHat 9.0--and probably Fedora current--uses NPTL, I 
personally don't feel that NPTL is quite production-ready 
(nothing against redhat, mind you, it's just that NPTL hasn't 
been out long enough to fully mature).

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"