On 07/08/2011 11:00 AM, Bruce Dubbs wrote: >> 2) rm "$SRCDIR"/procps-3.2.8-fix_HZ_errors-1.patch || exit 1 > >> The path has a "//" which means -p1 winds up with an absolute path after >> discarding one "/". > > I'm not sure what you mean here with the 'rm ... |exit 1', but the patch > applies cleanly for me:
Sorry, a cut and paste from my build script which I forgot to clean up. I mean that the patch contains this: diff -Naurp procps-3.2.8-orig//proc/sysinfo.c procps-3.2.8//proc/sysinfo.c --- procps-3.2.8-orig//proc/sysinfo.c 2008-03-23 23:33:43.000000000 -0500 +++ procps-3.2.8//proc/sysinfo.c 2010-09-20 01:13:36.000000000 -0500 Note the double slash. Busybox patch when told to "-p1" that path removes the first slash, and then tries to patch /proc/sysinfo.c at an absolute path. Gnu patch (being larger and more complicated) has an extra check for multiple consecutive slashes. What the standard requires depends on what "path component" means... (Rummage, rummage...) http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_266 Ok, bug in busybox I should fix. Still, the patch doesn't need two consecutive slashes in it triggering this bug in the current busybox release version. > $ patch -Np1 -i ../procps-3.2.8-fix_HZ_errors-1.patch > patching file proc/sysinfo.c > $ > > I can fix that, but since you are deviating from the book (vii. Host > System Requirements), I keep meaning to write an "Embedded Linux From Scratch". The smallest system capable of rebuilding itself under itself is 7 packages (busybox, uClibc, binutils, gcc, bash, make, and linux). I had to extend busybox significantly to make that work, but it does now. (Admittedly that's using the last GPLv2 releases of binutils and gcc, 2.17 and 4.2.1. The current versions are written in C++ and spilled some of their internal components into three or four more packages. GNU code has always been subject to Gates' law...) > it is not a high priority. You could edit the > patch file manually or use a sed on it. Right now I'm just deleting it (hence the "rm" above). It isn't fixing a bug I've actually hit, and if it was important it would presumably be fixed in procps upstream. Thanks, Rob -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
