From: Arkadiy Chapkis - Arc (achapkisshells.dls.net)
Date: Thu Nov 13 2003 - 09:40:11 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Just found out yesterday that Compaq's jdk is using GLIBC2.0 compatibility
modules in glibc-2.2.4 Since I built my glibc-2.3.2 without it, libjava (and
possibly more things related to jdk) didn't want to work. No big deal for me,
but maybe for someone else. I wonder if GNU classpath would be a good
replacement for jdk.

>
>Thanks, Kelledin. Your answers helped a lot. I'm going to use headers from
>kernel 2.6.0-test9. I'll just use --enable-add-ons to include all available
>add-ons -- hopefully all of them are already there.
>
>I'll send an update on the progress later.
>
>Thanks again.
>
>Rajiv
>
>----- Original Message -----
>From: "Kelledin" <kelledin+AXPskarpsey.dyndns.org>
>To: <axp-listredhat.com>
>Sent: Tuesday, November 11, 2003 10:53 PM
>Subject: Re: building glibc-2.3.2 on 164SX
>
>
>> 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 <bugsgnu.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 <bugsgnu.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?"

                                      Arc C.
                                      achapkisdls.net

_______________________________________________
axp-list mailing list
axp-listredhat.com
https://www.redhat.com/mailman/listinfo/axp-list

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]