Subject: Libc in CVS

From: [email-masked]
Date: Mon, 24 Nov 1997 05:41:08 +0100

Hi all,

with the bug fixes I checked in during the last few days libc is now
pretty stable.  In particular the problems with wrong relocations in
the X libraries and all libpam clients are working now.

Still to do:

 - some of the fixes are not very nice or correct at all
 - build binaries for redistribution.  Can somebody take care of this?

Given that this opens the way to useable native X libraries, which makes
building a large number of other RPM packages possible, these patches
are quite a breakthough.

  Ralf

---

From: [email-masked] (Alan Cox)
Date: Mon, 24 Nov 1997 09:46:35 +0000 (GMT)

> building a large number of other RPM packages possible, these patches

With luck it'll also fix the rpm-2.4.8 core dump bug which seems to be
bad linking. I'll turn the RPM factory back on

---

From: [email-masked]
Date: Mon, 24 Nov 1997 12:05:49 +0100

On Mon, Nov 24, 1997 at 09:46:35AM +0000, Alan Cox wrote:
> bad linking.

My rpm has never dumped core but it was complaining about nonexisting
users while creating the binary rpm file even though the user was
existing thus failing to build.  That rpm problem is fixed.

> I'll turn the RPM factory back on

All the source RPM packages on linus are known to build and work for
little endian targets.  Some of them, for example ncompress, have special
modifications to support big endian targets.

  Ralf

---

From: [email-masked] (Alan Cox)
Date: Mon, 24 Nov 1997 11:30:41 +0000 (GMT)

> existing thus failing to build.  That rpm problem is fixed.

Yep thats the bug - I also got some crashes. It was caused by getpw* failing
in peculiar ways. My RPM binary has its own 

> modifications to support big endian targets.

Im actually trying to build a full RedHat 5.0 by early December so Im picking
up your changes to stuff like bash indirectly via redhat on the whole. I can
then merge anything that escaped and together we can make sure they are in 
RH5.1.

Obviously as of about Dec1 the amount of answers I can get from RedHat will
noise dive for a couple of months

Alan

---

From: [email-masked]
Date: Mon, 24 Nov 1997 14:18:04 +0100

> in peculiar ways. My RPM binary has its own 

For rpm the trick is easy, just don't use a static linked binary.
Unfortunately the Redhat guys seem to think static binaries are a good
idea and install a static rpm by default.  Which it is not, not even
without a buggy dynamic linker.

> then merge anything that escaped and together we can make sure they are in 

Ok.  I stopped communicating with the Redhat guys shortly before I left the
US.  Essentially they received a part of the patches that I don't classify
as ugly hacks or work in progress.

Some more packages like the binutils, gcc or libc are based on different
versions and we should try to base our work on the same versions as Redhat
does.

> noise dive for a couple of months

:-)

  Ralf

---

From: [email-masked] (Alan Cox)
Date: Mon, 24 Nov 1997 14:09:12 +0000 (GMT)

> without a buggy dynamic linker.

Static rpm 2.4.8 +fixes works
Dynamic 2.4.8 crashes on startup every time

> as ugly hacks or work in progress.

No problem

> versions and we should try to base our work on the same versions as Redhat

Right now Ive got chunks of bastardised 4.8 (eg with -O not -O2 to avoid
gcc blowing up on zsh) but hopefully I can knock those out over time

---

From: Erik Troan <[email-masked]>
Date: Mon, 24 Nov 1997 10:55:25 -0500 (EST)

> without a buggy dynamic linker.

A static RPM has saved my ass *many* times, and it would irresponsible
for us not to ship it static. Glibc ought to be able to generate
static binaries. If it can't, it's broken.

Erik

-------------------------------------------------------------------------------
|       "For the next two hours, VH1 will be filled with foul-mouthed,        |
|          crossdressing Australians. Viewer discretion is advised."          |
|                                                                             |
|       Erik Troan   =   [email-masked]     =    [email-masked]          |

---

From: [email-masked]
Date: Mon, 24 Nov 1997 18:16:31 +0100

On Mon, Nov 24, 1997 at 10:55:25AM -0500, Erik Troan wrote:
> for us not to ship it static.

I'm not arguing against static binaries because we've got a bug in the
libs.

 - static binaries contain syscalls and therefore make it very difficult,
   if not impossible to modify the kernel interfaces.

   The SVID btw., explicitly forbids embedding syscalls into ABI compliant
   binaries.  While SVID compliance is not directly mandatory for Linux,
   binary compatibility issues with IRIX (or Solaris or ...) etc. might
   somewhen enforce modifications to the syscall interface resulting in
   broken static binaries.

 - many static binaries will use dlopen() to load _shared_ libraries under
   certain circumstances.  Rpm is just one of them.  For example try with
   your static rpm

     rm -f /lib/*.so*
     rpm --install ftp://ftp.whitehat.org/libc-2.0.5-.rpm

   Won't work, because you don't have your shared libc and libnss anymore ...
   I admit that this type of desaster recovery was nicer with Linux libc
   which doesn't do the dlopen() thing.

> Glibc ought to be able to generate static binaries. If it can't, it's broken.

Yes, and the bugs have been fixed.

  Ralf

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 24 Nov 1997 13:35:29 -0800

Date: Mon, 24 Nov 1997 10:55:25 -0500 (EST)
   From: Erik Troan <[email-masked]>

   A static RPM has saved my ass *many* times, and it would
   irresponsible for us not to ship it static. Glibc ought to be able
   to generate static binaries. If it can't, it's broken.

That was a nice thing back in the pre-glibc days.  But since so many
static binaries (including RPM) pull in the NIS stuff dynamically via
dlopen() due to how GLIBC works, your ass will no longer get saved the
way it used to.

Later,
David S. Miller
[email-masked]

---

From: Erik Troan <[email-masked]>
Date: Mon, 24 Nov 1997 16:58:22 -0500 (EST)

> dlopen() due to how GLIBC works, your ass will no longer get saved the

At least you can install the packages though. At the very worst, 
getpwnam() will fail and RPM will use root.root for all of the files,
but at least they will be there. That's surely better then not being
able to install packages at all.

Erik

---

From: [email-masked]
Date: Tue, 25 Nov 1997 00:22:31 +0100

> able to install packages at all.

I just checked mount(8), it's a shared binary.  I guess only the fewest
Redhat installations it is possible to access the packages without using
nss services or mount.

Aside, if everything gets installed as root.root in absence of the nss
functionality this open a theoretical security problem for some packages.

  Ralf