Bug 13343

0) I can confirm this problem on current Fedora Rawhide (which should be close to reporter's Fedora 11) and v2.6.30-rc8.

1) The error is caused because vmlinux.lds contains linemarkers:
$ head arch/um/kernel/vmlinux.lds
# 1 "arch/um/kernel/vmlinux.lds.S"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "./include/linux/autoconf.h" 1
# 1 "<command-line>" 2
# 1 "arch/um/kernel/vmlinux.lds.S"



# 1 "arch/um/kernel/dyn.lds.S" 1

2) This is the command to build vmlinux.lds:
$ head -1 arch/um/kernel/.vmlinux.lds.cmd 
cmd_arch/um/kernel/vmlinux.lds := gcc -E -Wp,-MD,arch/um/kernel/.vmlinux.lds.d  -nostdinc -isystem /usr/lib/gcc/i586-redhat-linux/4.4.0/include -Iinclude  -I/home/[...]/.sandbox/linux-2.6/arch/um/include -include include/linux/autoconf.h -D__KERNEL__ -I/home/[...]/.sandbox/linux-2.6/arch/um/sys-i386 -I/home/[...]/.sandbox/linux-2.6/arch/x86/include    -D__ASSEMBLY__ -o arch/um/kernel/vmlinux.lds arch/um/kernel/vmlinux.lds.S

3) UML builds correctly on (current) Fedora 10, also using v2.6.30-rc8. There the command to build vmlinux.lds is:
$ head -1 arch/um/kernel/.vmlinux.lds.cmd 
cmd_arch/um/kernel/vmlinux.lds := gcc -E -Wp,-MD,arch/um/kernel/.vmlinux.lds.d -nostdinc -isystem /usr/lib/gcc/i386-redhat-linux/4.3.2/include -Iinclude -I/home/[...]/.sandbox/linux-2.6/arch/um/include -include include/linux/autoconf.h -D__KERNEL__ -I/home/[...]/.sandbox/linux-2.6/arch/um/sys-i386 -I/home/[...]/.sandbox/linux-2.6/arch/x86/include   -Ui386 -DSTART=0x8048000 -DELF_ARCH=i386 -DELF_FORMAT="elf32-i386" -DKERNEL_STACK_SIZE=4096 -P -C -Uum -D__ASSEMBLY__ -o arch/um/kernel/vmlinux.lds arch/um/kernel/vmlinux.lds.S

Note that a number of important options in the command to build vmlinux.lds that are used here aren't used in the (incorrect) Fedora Rawhide command.

4) Confusingly, on (current) Fedora Rawhide a straightforward i386 bzImage builds correctly. Then the command to build vmlinux.lds is:
$ head -1 arch/x86/kernel/.vmlinux.lds.cmd 
cmd_arch/x86/kernel/vmlinux.lds := gcc -E -Wp,-MD,arch/x86/kernel/.vmlinux.lds.d  -nostdinc -isystem /usr/lib/gcc/i586-redhat-linux/4.4.0/include -Iinclude  -I/home/[...]/.sandbox/linux-2.6/arch/x86/include -include include/linux/autoconf.h -D__KERNEL__   -P -C -Ui386 -Ui386 -D__ASSEMBLY__ -o arch/x86/kernel/vmlinux.lds arch/x86/kernel/vmlinux.lds.S

5) So, this could simply be a bug in the Fedora Rawhide build utilities which is not triggered when building an i386 bzImage. But maybe this is also something tricky in the Kconfig/Kbuild setup that only triggers an error in Fedora Rawhide's build utilities. However, I haven't yet found a suspect in a  quick look in (some of) the relevant Makefiles.

confirmed 2) on 2.6.29.3, the command is the same
seems something related to the jump to default i586

0) For some reason CPPFLAGS_vmlinux.lds is empty when trying to build with ARCH=um. This is easily determined by putting lines like this
    $(warning CPPFLAGS_vmlinux.lds: $(CPPFLAGS_vmlinux.lds))
at the start (and other interesting locations) of all Makefiles in arch/um (and in the relevant arch/x86 Makefiles for counter examples).

1) The difference between Fedora 10 and Fedora Rawhide, hinted at in comment #1, might not be relevant. At least, downgrading make (and some other packages) on Fedora Rawhide to their Fedora 10 versions did not resolve this issue. This issue might be triggered by something else (note that I tested Fedora 10 and Fedora Rawhide on separate machines).

2) I haven't yet discovered what actually is going on here ...

(In reply to comment #3)
> 0) For some reason CPPFLAGS_vmlinux.lds is empty when trying to build with
> ARCH=um.

To be more precise: it is set (correctly) in arch/um/Makefile and updated (again correctly) in the main Makefile but somehow never set in any other Makefile.

I confirm the bug, and it comes from bash4, this thread gives some explanations on the reason why it fails: http://thread.gmane.org/gmane.linux.uml.devel/12205

Created attachment 23022 [details]
hack to work around bash 4 build failure

0) Thanks for the pointer in comment #5. I hadn't considered bash as one of the possible culprits.

1) v2.6.31 is imminent. The discussion concerning bash's behaviour for environment variables seems to be going nowhere. So maybe the attached quick hack should be considered for inclusion in v.2.6.31.

2) This hack shouldn't break the build on other shells. Could someone confirm?

3) Maybe someone more familiar with make, Makefile syntax, etc. could come up with a real fix, but otherwise a quick hack like the one attached will have to do for now.

Feel free to add my Tested-by: Florian Fainelli <florian@openwrt.org>, this works fine.

Even more interesting, building UML with SHELL=/bin/sh which is a symbolic link to /bin/bash works, while building with SHELL=/bin/bash does not. Anyway your fix works for me when the shell is not specified or SHELL=/bin/bash.

Please make sure this goes in 2.6.31-rc10.

Your fix does not break bash3 either. It might be worth to mention that the patch fixes builds on Fedora Core 11 and current Debian Testing which also recently switched to using bash4. Thanks !

Fixed (properly, it seems, and for a number of architectures) with  51b563fc93c8cb5bff1d67a0a71c374e4a4ea049 ("arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0") in 2.6.32-rc2. Please CLOSE, RESOLVE, or WHATEVER this bug.