This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: glibc and Unix98 PTY's
>>>>> Zlatko Calusic writes:
Zlatko> Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:
>>
>> - This version of glibc is a _test_ release of glibc 2.1. We (glibc
>> developers) tested it and it did work in our environment. We don't
>> consider it of release quality and therefore encourage users to test
>> it and tell us about problems. Problems should be reported direclty
>> to the glibc maintainer Ulrich Drepper <drepper@cygnus.com>.
Zlatko> I have some bug reports, even on 2.0.7 version. Should I really send
Zlatko> them directly to Ulrich. Is linux-gcc@vger maybe a better place?
As I've said above: Report problems on the test release directly to
Ulrich. Problems in released versions should always reported with the
glibcbug script. Btw. if you use the glibcbug script from glibc
2.0.95 it will report always to the correct address. linux-gcc is the
wrong place - see the file BUGS for further details.
>>
>> - The current version contains some patches to make the build process
>> faster. A lot of people complained that it takes too long to
>> compile glibc and Zack finally managed to make some real
>> improvements[1]. Sadly this broke one special case: Building in the
>> source directory. We've always advocated to build glibc in an extra
>> build directory:
>> >The `best' way to build glibc is to use an extra directory, e.g.:
>> >tar xzf libc-970921.tar.gz
>> >mkdir build-glibc
>> >cd build-glibc
>> >../libc-970921/configure ...
>> This is how we build glibc and therefore should always work. I'd
>> advise everybody to use a build directory to build glibc -
>> independent of the version.
Zlatko> Huh, OK. This one I wouldn't know without you.
It should work now also with building in the source directory - but a
separate build directory has some advantages.
>>
>> - Good sense dictates that you should only work temporarily as root.
>> Especially for running make or make check you don't need root
>> privilegs. glibc 2.0.93 contained one testcase (io/ftwtest-sh)
>> which fails if you run `make check' as root. Thanks to the reports
>> we've got, this test is now only run for non-root users.
>>
>> - When upgrading glibc you should always have a backup of libc lying
>> around so that you easily can call programs if the update fails:
>>
>> LD_LIBRARY=/libc-backup /libc-backup/ld-linux.so.2 /bin/sh
Zlatko> You mean, LD_LIBRARY_PATH?
Yes, you're right.
Zlatko> How about putting new libc in the same directory (/lib) and then using
Zlatko> LD_PRELOAD=/lib/libc.so.needed_ver some_executable?
I don't know - but the problem is you need to call ld-linux.so.2 since
libc and ld-linux have to match.
>>
>> - There're still some problems when upgrading from glibc 2.0.6/7 to
>> glibc 2.1 test releases. IMHO the best way is to install everything
>> in a temporary directory and then copy it in single user mode:
>>
>> make install install_root=/temporary-dir
>> (cd /temporary-dir ; tar -clf - etc lib usr) | (cd / ; tar -xpf -)
>>
>> The problem is that during install some atomar operation are needed
>> but at the moment atomicity isn't guaranteed.:-(
Zlatko> Scary stuff... brrr :)
Zlatko> I prefer "cp -a" for thigs like this (much shorter and less prone to
Zlatko> mistakes than multiple tars).
I'm not sure what happens if one of the libraries you're overwriting
is open with cp. It might be possible to upgrade with just `make
install'- but I'm not sure - but we do try to get this
bullet-proof;-).
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@alma.student.uni-kl.de