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: [Failure]compiling glibc on MKlinux


>>>>> John Kennedy writes:

John> [Trevor Johnson]
>> Try the method described in Andreas' Jaeger's message "Comment on
>> glibc 2.0.93": ...

John>   Haven't seen it.  I *did* see the "The `best' way to build glibc..."
John> quote in the README-alpha file in the libc-980503 snapshot, but I didn't
John> see a similar file in 2.0.93 (plus enough elapsed time that I forgot it)
John> so I neglected to modify my build script.

I didn't distribute the mail very far but I'm appending it now and
hope it's helpful.

Andreas

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upgrading from glibc 2.0.7 to glibc 2.1 shouldn't be a big problem.
Currently there are still some 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:

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.

- 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?').


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

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]