On Thu, Apr 22, 2010 at 12:10 PM, Michael Deutschmann <[email protected]> wrote: > On Thu, 22 Apr 2010, Natanael Copa wrote: >> Do you have any better suggestions how to upgrade a running system? > > First, build the new uClibc, but don't install it yet. > > Build a customized ld-uclibc.so.0, from the previous uClibc source, that > looks in a different place for shared libraries and ignores the > /etc/ld.so.* files. Install it under a different filename. > > Write a utility to modify the INTERP filename specified in an executable > from "/lib/ld-uclibc.so.0" to the filename of the special ld.so. (This is > much simpler if the temporary ld.so filename is the same length as the > original.) > > Hardlink the existing shared libraries into the alternate position, then > hack every existing installed executable in this way. > > Then, delete all the old libraries in /usr/lib and the include files. The > shared libraries will be preserved by the hardlink, while everything else > is dispensible. The system should still work for everything except > compilation. > > Now, install the new uClibc. Unless the ABI is so thoroughly broken as > to invalidate the old specs or libgcc.a, you should now be able to compile > new binaries. > > I intend to do something like this for my 0.9.30.3 to 0.9.31 rollover, > but I haven't finished writing the necessary utilities yet.
I have hard time to understand how that is superior to change sonames: old gcc-x.y-1 and old apps are linked to libc.so.0 compile libc.so.0.9.31 and upgrade (replace) developerment package and install new libc runtime side-by side. At this point all binaries/libs will work as excepted, just like with your hardlink trick (except instead of hardlinking you use different names) but new packages will be linked to libc.so.0.9.32. with old gcc rebuild gcc-x.y-2 with libc.so.0.9.32 as dependency. do the same with every other package in dependency order. Package manager can safely keep track of what package it needs to work properly. Thats what package managers are for and that is how most distros handles abi changes in libraries. Yes i know uclibc is not really targetting packagemanagers, but making ABI_VERSION overrideable will make it work, even if other might prefer ugly hacks with hardlinking and moving binaries. -- Natanael Copa _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
