Bug in wc.

[Rob Landley]

The busybox "wc" command doesn't work to build mips in 2.6.33.  Kernel commit 
1b93b3c3e94be2605 added multiple compression types to the kernel image, and 
that means that my build is now dying at the end with:

  LD      vmlinuz
  mips64-ld: invalid hex number `0x'

And the actual command line mips64-ld is getting called with is:

mips64-ld "-m" "elf64btsmip" "-m" "elf64btsmip" "-Ttext" "0x" "-T" 
"arch/mips/boot/compressed/ld.script" "arch/mips/boot/compressed/head.o" 
"arch/mips/boot/compressed/decompress.o" "arch/mips/boot/compressed/dbg.o" 
"arch/mips/boot/compressed/piggy.o" "-o" "vmlinuz"

The -Ttext option in ld is generated in arch/mips/boot/compressed/Makefile 
which does:

  LDFLAGS_vmlinuz := $(LDFLAGS) -Ttext $(VMLINUZ_LOAD_ADDRESS) -T

And VMLINUZ_LOAD_ADDRESS is calculated earlier in that file as:

VMLINUZ_LOAD_ADDRESS := 0x$(shell [ -n "$(VMLINUX_SIZE)" -a -n "$(LOW32)" ] && 
printf "$(HIGH32)%08x" $$(($(VMLINUX_SIZE) + 0x$(LOW32))))

And VMLINUZ_SIZE is:

VMLINUX_SIZE := $(shell wc -c $(objtree)/$(KBUILD_IMAGE) 2>/dev/null | \
	cut -d' ' -f1)

VMLINUX_SIZE is blank when using busybox tools.

The underlying behavioral wonkiness in busybox "cut" is:

$ busybox wc -c vmlinux
  3335777 vmlinux
$ wc -c vmlinux
3335777 vmlinux

Note that we have leading whitespace, the gnu version doesn't.  This leading 
whitespace is confusing the kernel build, because the cut -d' ' then triggers 
on our leading whitespace and produces an empty string, which propogates 
through the rest of the build to confuse the linker with a start address of 
"0x".

Why do we have unnecessary leading whitespace?  What happend to small and 
simple and doing no more than absolutely necessary?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds