> >Well I've been called a lot of things, but not a "random user" before ;)
> >I don't think I should have to recompile all the tools to `static` if I
> >wish to rebuild glibc with the "latest-and-greatest" compiler. This
> >problem is certainly going to come up again. If the developers of ld.so
> >would respond, maybe its as simple as renaming ld.so.cache before
> >`make install`.
>
> It's not really an ld.so problem. All the binaries currently running on your
> system will have libc.so and other libraries mmap'd. If you install a new
> copy of libc.so on top of the old one, without either deleting or moving the
> old library out of the way, the effect will be that these running programs end
> up with a random mixture of pages from the old and new libraries. This
> internal inconsistency is what leads to the crash. If you get a crash during
> installation of libc your system can be left in an inconsistent state and
> quite possibly this will mean that no binaries at all will run.
>
> By either deleting or moving libc.so.6 prior to installation you ensure that
> currently-running programs retain an intact copy of the old library; new
> programs will get the new library (also hopefully intact) and everybody is
> happy.
>
This sounds correct. However, the `make install` does just this on
a per-library basis, never overwriting the original. However, since
during the process, you continually create new tasks, soon new tasks
will be using binaries from an incomplete install (you can't change
ld-linux.so.x and glibc-x.so at the exact same time).
If you have different version numbers, you don't have this problem.
So. I think that `install` and `mv` has to be linked static before
such an install, perhaps even /bin/bash. There are other ways. I
could modify the make file to install everything in /new/local/lib and
/new/bin (/new instead of /usr), then merge everything by hand.
This is a pain. I still think the solution lies with ld.so.cache. If
ld.so did not reload its cache except after an explicit command, i.e.,
`ldconfig`, and the cache pointed to already-mapped libraries, there
would not be such a problem at all.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/