[U-Boot-Users] Compile error: option `-g' is ambiguous

[Timur Tabi]

I just pulled the latest tree and tried building for MPC8349EMDS, I got this:

make -C examples all
make[1]: Entering directory `/temp/u-boot.i2c/examples'
powerpc-unknown-linux-gnu-gcc -g  -Os   -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xFE000000  -I/temp/u-boot.i2c/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC83XX -DCONFIG_E300 -ffixed-r2 -ffixed-r29 -msoft-float -Wall -Wstrict-prototypes -c -o hello_world.o hello_world.c
powerpc-unknown-linux-gnu-gcc -g  -Os   -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xFE000000  -I/temp/u-boot.i2c/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC83XX -DCONFIG_E300 -ffixed-r2 -ffixed-r29 -msoft-float -Wall -Wstrict-prototypes -c -o sched.o sched.c
powerpc-unknown-linux-gnu-gcc -Wa,-g -D__ASSEMBLY__ -g  -Os   -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xFE000000  -I/temp/u-boot.i2c/include -fno-builtin -ffreestanding -nostdinc -isystem /_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/include -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC83XX -DCONFIG_E300 -ffixed-r2 -ffixed-r29 -msoft-float -c -o ppc_longjmp.o ppc_longjmp.S
/_TOOLS_/.dist0/gnu-gcc-3.4.3-binutils-2.15-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/3.4.3/../../../../powerpc-unknown-linux-gnu/bin/as: option `-g' is ambiguous
make[1]: *** [ppc_longjmp.o] Error 2
make[1]: Leaving directory `/temp/u-boot.i2c/examples'
make: *** [examples] Error 2

Unfortunately, I wasn't paying much attention to the recent -g discussion, but it looks like whatever changes were made breaks the 8349EMDS.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale