Bryan Kadzban wrote:
> 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).
I've heard that something like
tar -c - file1 file2 | tar -x -C somedir
may work too. It's just that everything needs to work in one invocation.
> (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.
Agree.
> 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. :-)
Actually I don't think updating udev would be a problem as long as the
/sys format doesn't change. In my case, it definitely does.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
