Bruce Dubbs wrote: > Also, as with the discussion on BLFS support discussing updating > glibc in place, I think I will put udev in the same category as too > risky to update in place.
Maybe. As to upgrading glibc directly -- as long as you replace both
the ld-linux* symlink and the libc.so.* symlink in the same PID (copy
the target files into /lib{,64}, then from a single PID, unlink both
symlinks and point them to the new files). Of course it's impossible to
do this from shell; you have to write a program that does it, and which
doesn't exec() anything in the process. You have to make the symlink()
syscall twice in the one PID.
Might also work to "cp --remove-destination", if that works on a symlink
(haven't tried it).
(You also have to make sure you're not overwriting the current target of
the links on your system. Not sure which glibc versions do this and
which don't, but replacing e.g. ld-2.10.1.so with itself isn't going to
end well unless you unlink the old version and copy over the new, and
then you have to do *that* in the same PID as the one that fixes the
symlinks.)
Definitely not supported by the installation procedure of glibc itself,
of course. It's possible, but probably not a good idea.
Anyway, as for udev, I've been able to upgrade it in small chunks (no
more than ~10-20 versions at a time), with some work to handle the new
version in some cases. However, if you're on -071 now, that's going to
be hard. Not supporting it in the book is probably a good idea. :-)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
