This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: glibc and Unix98 PTY's


>>>>> Zlatko Calusic writes:

 > Ulrich Drepper <drepper@cygnus.com> writes:
>> Zlatko Calusic <Zlatko.Calusic@CARNet.hr> writes:
>> 
>> > Now, the question *is*, can I use glibc 2.0.95 safely?
>> 
>> Many people run 2.0.9x libcs as the main libc (myself included) and
>> have no problems.

 > Thanks. I was only wondering are there some hidden gotchas.

No - you just should be careful and have a backup handy.;-)

I'm appending a message I've written originally for 2.0.93 and which
explains some caveats.  You also have to recompile your c++-library
when upgrading from 2.0.7 to 2.0.95 but egcs has problems due to some
changes in glibc 2.0.95.  Solutions have been suggested, e.g. on the
egcs-bugs mailing list.

Andreas

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upgrading from glibc 2.0.7 to glibc 2.1 shouldn't be a big problem.
Currently there are still some small problems - and therefore glibc
2.1 is still not released.  In this document, I'd like to point out
some points you should be aware of when upgrading.

- Besides reading this file you should check the FAQ.  The FAQ
  gives also hints about some general problems.

- 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>.

- 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.

- 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

- 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.:-(

- glibc 2.1 contains the localedata add-on which was formerly separate 
  - and quite a lot more.  For details read e.g. the NEWS file.  The
  only add-ons that exists for now are the crypt and linuxthreads
  add-on.  Please get in both cases the 2.0.93 version - the 2.0.6/7
  version doesn't work with 2.1 and the other way round.

- gcc 2.7.2.3 is broken.  A glibc 2.0.93 build which gcc 2.7.2.3
  wouldn't even pass `make check'.  We're therefore enforcing the use
  of newer gccs (egcs and gcc 2.8.1) to build glibc.

- When building glibc you should use the most recent Linux kernel
  headers.  The headers used while compiling the GNU C library and the
  kernel binary used when using the library do not need to match.  The
  GNU C library runs without problems on kernels that are older than
  the kernel headers used.  The other way round (compiling the GNU C
  library with old kernel headers and running on a recent kernel) does
  not necessarily work.  For example you can't use new kernel features
  when using old kernel headers for compiling the GNU C library.

  If you're running 2.0.33 and never want to upgrade to Linux 2.1,
  then use the 2.0.33.  But if you plan to upgrade, you should compile
  with recent 2.1 kernel headers.

- Don't remove libdb.so.2/libdb-2.0.7.so and libnss_*-2.0.7.so since
  old programs might still use it.

- If you're running g++ programs, you've got to recompile libstdc++
  and libg++.  For details see the FAQ entry (`What do I need for C++
  development?').

Neccessary patches for glibc 2.0.95:

1998-07-30  Richard Henderson  <rth@cygnus.com>

	* elf/Makefile (ld-map): Move initialization below Makeconfig include.

Index: elf/Makefile
===================================================================
RCS file: /egcs/carton/cvsfiles/libc/elf/Makefile,v
retrieving revision 1.95
diff -u -p -r1.95 Makefile
--- Makefile	1998/07/27 17:42:09	1.95
+++ Makefile	1998/07/30 05:04:46
@@ -35,9 +35,6 @@ elide-routines.os = $(dl-routines) dl-su
 # ld.so uses those routines, plus some special stuff for being the program
 # interpreter and operating independent of libc.
 rtld-routines	:= rtld $(dl-routines) dl-sysdep dl-environ dl-minimal
-ifeq ($(versioning),yes)
-ld-map		= $(common-objpfx)libc.map
-endif
 distribute	= $(rtld-routines:=.c) dynamic-link.h do-rel.h dl-machine.h \
 		  dl-hash.h soinit.c sofini.c ldd.sh.in ldd.bash.in eval.c \
 		  genrtldtbl.awk atomicity.h dl-procinfo.h ldsodefs.h \
@@ -53,6 +50,10 @@ before-compile = $(objpfx)trusted-dirs.h
 all: # Make this the default target; it will be defined in Rules.
 
 include ../Makeconfig
+
+ifeq ($(versioning),yes)
+ld-map		= $(common-objpfx)libc.map
+endif
 
 ifeq (yes,$(build-shared))
 extra-objs	= $(rtld-routines:=.os) soinit.os sofini.os eval.os interp.os


I hope I didn't confuse anybody;-)
Andreas Jaeger
aj@arthur.rhein-neckar.de


Footnotes: 
[1]  Sorry, I don't have measurements for this.

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@alma.student.uni-kl.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]