Subject: libc upgrade

From: Ralf Baechle <[email-masked]>
Date: Fri, 22 Sep 2000 15:26:04 +0200

I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com.  The
rpm package filenames are:

  glibc-2.0.6-6lm.src.rpm,
  glibc-2.0.6-6lm.mips.rpm,
  glibc-devel-2.0.6-6lm.mips.rpm,
  glibc-profile-2.0.6-6lm.mips.rpm,
  glibc-debug-2.0.6-6lm.mips.rpm

This release fix a number of bug that have been hanging in the dynamic
linker basically forever and is urgently recommended to install.

Once more rpm in it's stupidity being a static linked program breaks.  I
therefore also provide new rpm binaries:

  rpm-3.0-6.0lm.mips.rpm
  rpm-devel-3.0-6.0lm.mips.rpm

No new source package for rpm since this is just a recompile of the
package.  Not that also other software which has been statically linked
against libdl needs to be rebuilt against this library release.

IMPORTANT: you must install these new rpm binaries before you upgrade
glibc!

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 25 Sep 2000 11:24:13 +0200

> rpm package filenames are:

Build fails on mipsel ...

gcc rpcinfo.c -c -O2 -g -w     -I. -I.. -I../libio  -I../sysdeps/mips/elf -I../crypt/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips -I../linuxthreads/sysdeps/pthread/cmpxchg -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel -I../sysdeps/mips -I../sysdeps/wordsize-32 -I../sysdeps/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic -I../sysdeps/stub  -D_LIBC_REENTRANT -D_PATH_RPC='"/etc/rpc"' -include ../libc-symbols.h     -o rpcinfo.o
gcc -nostdlib -nostartfiles -o rpcinfo  -Wl,-dynamic-linker=/lib/ld.so.1 -g ../csu/start.o ../csu/crti.o `gcc --print-file-name=crtbegin.o` rpcinfo.o  -Wl,-rpath-link=..:../elf:../nss ../libc.so.6 ../elf/ld.so.1 ../libc.a -lgcc `gcc --print-file-name=crtend.o` ../csu/crtn.o
/bin/sh: invalid character 45 in exportstr for full-config-sysdirs
LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T
/bin/sh: invalid character 45 in exportstr for full-config-sysdirs
make[1]: *** [xbootparam.stmp] Segmentation fault
make[1]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.0.6/sunrpc'
make: *** [sunrpc/others] Error 2
Bad exit status from /var/tmp/rpm-tmp.29023 (%build)

Flo
-- 
Florian Lohoff		[email-masked]		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 25 Sep 2000 13:20:56 +0200

> Build fails on mipsel ...

These messages look like file corruption.  Maybe one of the `features'
of the 2.4.0-test kernels and not libc at all?

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 25 Sep 2000 16:15:00 +0200

> of the 2.4.0-test kernels and not libc at all?

I dont think so - I succeeded to compile ~2000 Packages of debian
on this kernel and its noticeably the first execution with the "new" ld.so

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 25 Sep 2000 22:14:14 +0200

> on this kernel and its noticeably the first execution with the "new" ld.so

I week of CPU time on an Origin building packages:  No problems ...  I'm
actually fairly close to get a RH 6.2 built - as far as that is possible
with glibc 2.0.

> make[1]: *** [xbootparam.stmp] Segmentation fault

Ok, second theory.  What linker where you using to build all this programs?
The new ld.so needs to know what ld has built programs due to some pretty
stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 26 Sep 2000 01:04:16 +0200

> stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling.

egcs 1.0.3a binutils 2.8.1 (Very conservative)

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 26 Sep 2000 02:46:56 +0200

> egcs 1.0.3a binutils 2.8.1 (Very conservative)

That's actually the one combination I haven't tested.  Looking into it and
don't hold your breath :-(.

  Ralf

---

From: "Gleb O. Raiko" <[email-masked]>
Date: Tue, 26 Sep 2000 12:30:03 +0400

Ralf,

BTW, what should we use as system headers with glibc nowadays ? Should
it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ?

> actually fairly close to get a RH 6.2 built - as far as that is possible

Do you have the packages somewhere on the net ? I am personally
interested in disk packages (fdisk, msdostools &co.) and the packages
required in order to run 2.2 kernels. Old HardHat cfdisk, for example,
seems to create partitions in the big endian format. At least, the rest
see garbage after cfdisk creates a partition table.

Regards,
Gleb.

---

From: "Gleb O. Raiko" <[email-masked]>
Date: Tue, 26 Sep 2000 12:37:57 +0400

> egcs 1.0.3a binutils 2.8.1 (Very conservative)

Well, another question. Ralf uploaded cross tools rpms year ago. Does
anybody have native rmps for big endian ? Also, does anybody have cross
tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile
cross gcc on my Ultra, it seems like a bug in the sparc compiler, the
process fails in parsing an enum decl in a header.

Regards,
Gleb.

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 26 Sep 2000 12:36:00 +0200

> process fails in parsing an enum decl in a header.

I tried to compile cross gcc/binutils from CVS a couple of times
for Linux/Sparc (Ultra) which didnt work as somewhere in the
middle the beast meant to use the native "as" instead of
mipsel-linux-as

Flo

---

From: Keith M Wesolowski <[email-masked]>
Date: Tue, 26 Sep 2000 10:48:05 -0700

> process fails in parsing an enum decl in a header.

Native rpms, no. Native tarballs that "work," yes. I do have cross
tools (again, not RPMs) for sparc glibc 2.1 - it's my main devel
environment. I also have a script that builds an entire cross
toolchain and kernel for any versions of gcc/binutils/glibc/kernel
that you supply, and it's tested mainly on sparc glibc 2.1. I have not
yet had any problems building such a cross toolchain, with a mainly
stock RH6.2 system (make has to be upgraded to build recent
glibc). Information on how I'm doing this is at
http://foobazco.org/~wesolows/mips-cross.html. I recommend using the
make-cross tools, however, located at
ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/. HTH.

-- 
Keith M Wesolowski			[email-masked]
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 26 Sep 2000 23:06:50 +0200

> middle the beast meant to use the native "as" instead of

gcc tries to run as on <prefix>/lib/gcc-lib/<target>/<version>/as, then
<prefix>/<target>/bin/as, then the native as from $PATH.  So check if you
were using the same target configuration name (mips-linux and
mips-unknown-linux-gnu are different!) for both gcc and binutils.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 27 Sep 2000 00:47:22 +0200

> it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ?

Definately not the old hardhat kernel headers.  I'm using 2.2 header and
recommend doing the same for best success with packages for current
distributions based on this kernel.  Building some packages may actually
require a newer version but in general the lastest 2.2 headers are the
best.

> see garbage after cfdisk creates a partition table.

I've got a hacked utils-linux package, I think it's in the redhat-6.0
packages that are on oss.  I don't really intend to upload all the stuff
to oss, they're just a big test for the changed compile environment which
I'm using, that is binutils-current and gcc-current.  Before I even fiddle
with stuff like glibc 2.2 etc. I want to know that the tools are reasonably
solid.  So far they seem to be good after applying a few minor but essential
patches.  Still need to test building a kernel.

  Ralf