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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox