link sort against libm. This adds 22 bytes for glibc but is a win for uClibc,
and since glibc is bigger than all of busybox it seems kind of silly to worry
about it.
Development:
bloatcheck - show size difference between busybox_unstripped
/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
make[1]: *** [help] Error 2
make: *** [help] Error 2
(with O=directory), and reverting them fixes building out of tree. I'd be
happy to fix them up instead of reverting them if I had the foggiest idea
what they were trying to do, but I don't, and this at least gets building
out of tree working again...
the side of the tree doesn't _COUNT_, and I will not ship it.
Udhcp was deleted shortly after I posted my philosophy for what should and
shouldn't go into busybox:
http://www.busybox.net/lists/busybox/2006-March/019484.html
I complained about the change t the time. I've complained repeatedly since.
But nobody felt like fixing it. External dependencies are something to be
minimized. I don't care about the ability for packages to build outside
busybox: something is either part of busybox, or it isn't. If I convert any
part of the external udhcp repository to use libbb, I've broken the external
package. Any random cleanups that touch that directory suddenly have to worry
about external dependencies that are NOT OUR PROBLEM. Therefore, that
directory is not and cannot be part of busybox. Wishful thinking isn't going
to change that. I will not ship something I can't maintain.
I'll try to get a new dhcp client and server in before the ship window closes,
but I have a half-dozen other projects pending. I'm sorry this happened, but
I'm not the one who removed it, and I'm not the one who ignored the project
maintainer's repeated complaints about the situation for the next month and a
half.
A tab is now taken as the end of filename if it's there, but if it isn't
(because the timestamp isn't there) we continue with the existing untruncated
line as the filename.
produced in the list ten years has some variant of internal error correction
(disks, cdrom, flash), so if it has user-visible bad blocks on it the
hardware has exhausted its remapping reserve and is dying, and you need to get
your data off pronto. (The one exception I can think of is floppies, and I
don't care.)
