On Thu, Sep 20, 2012 at 09:15:42AM +0200, Remco wrote: > AFAICT at least the tools in /bin and /sbin are statically linked and would > need to be rebuilt to include any changes in libc.
That's correct, and it's actually very convenient. If you make some mistake dynamic binaries might no longer be able to run because they fail to load libc. In that case, statically linked cp or mv can still fix your system if you have a backup of the original libc file. You can also crank the major library version in /usr/src/lib/libc/shlib_version before compiling your modified libc, so that only newly compiled programs will use it. > To take into account statically built binaries and since basically > everything else depends on libc, my advise is to rebuild/install at least > the whole base system from source. This way you should be able to test if > your system survives a reboot and some basic system usage with your changes > included. (You may actually need to build the base system once more to > check if the build itself didn't break) Usually, if you're hacking libc, you'll also be writing test programs that use the interfaces you're modifying or adding. It makes sense to run those little test programs before committing to rebuilding everything with the modified libc. Sometimes I even linked test programs directly to the libc in /usr/obj to save time (though I don't recall the details of how I did that -- I think it was easy for static linking but there were some impossible warp space hoops to jump through for the dynamic case). > Eventually xenocara and probably a ports bulk build would be necessary as > well. Yes. And building a release(8) and testing the resulting snapshot. I once broke disklabel(8), in the installer only, by changing libc (in the UTF-8 commit that was quoted on undeadly.org). Effects of libc changes tend to pop up in unexpected places. However, I suppose wrapping random() in a mutex can't break that much. Or can it? :)
