dylan: meta-toolchain and u-boot : "cannot find -lgcc"

Hi,

here is a problem I met while trying to build u-boot with a toolchain generated using dylan.

steps to reproduce :
- bitbake meta-toolchain for an armv5t target

- install the sdk to a custom path ($HOME/oecore-x86_64/ for example instead of /usr/local/oecore-x86_64/

- get u-boot :
git clone git://git.denx.de/u-boot.git
source ~/oecore-x86_64/environment-setup-armv5te-oe-linux-gnueabi make LDFLAGS="" ARCH=arm CROSS_COMPILE=arm-oe-linux-gnueabi-
da850evm_config
make LDFLAGS="" ARCH=arm CROSS_COMPILE=arm-oe-linux-gnueabi-

you will get :
arm-oe-linux-gnueabi-gcc -E -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0xc1080000 -DCONFIG_SPL_TEXT_BASE=0x80000000 -DCONFIG_SPL_PAD_TO=0 -DCONFIG_SPL_BUILD -I/data/testdylan/tmp/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /data/testdylan/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/armv5te-oe-linux-gnueabi/../../lib/armv5te-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.7.2/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5te -include /data/testdylan/tmp/u-boot/include/u-boot/u-boot.lds.h -include /data/testdylan/tmp/u-boot/include/config.h -DCPUDIR=arch/arm/cpu/arm926ejs -I/data/testdylan/tmp/u-boot/spl/. -ansi -D__ASSEMBLY__ -P - < /data/testdylan/tmp/u-boot/board/davinci/da8xxevm/u-boot-spl-da850evm.lds > /data/testdylan/tmp/u-boot/spl/u-boot-spl.lds
cd /data/testdylan/tmp/u-boot/spl/ && arm-oe-linux-gnueabi-ld.bfd -T /data/testdylan/tmp/u-boot/spl/u-boot-spl.lds --gc-sections -Bstatic -Ttext 0x80000000 arch/arm/cpu/arm926ejs/start.o --start-group arch/arm/cpu/arm926ejs/davinci/libdavinci.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o board/davinci/da8xxevm/libda8xxevm.o common/libcommon.o common/spl/libspl.o drivers/mtd/spi/libspi_flash.o drivers/serial/libserial.o drivers/spi/libspi.o lib/libgeneric.o --end-group /data/testdylan/tmp/u-boot/spl/arch/arm/lib/eabi_compat.o -L . -lgcc -Map u-boot-spl.map -o u-boot-spl arm-oe-linux-gnueabi-ld.bfd: cannot find -lgcc

this can be fixed by installing the sdk to it's standard path (/usr/local/oecore-x86_64/ in the present case).

Is that an expected behaviour (as the sdk is primarly designed to build applications) or can that be fixed during the sdk relocation ?

Thanks,
Eric

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 5 lines · Eric Bénard

this can be fixed by installing the sdk to it's standard path (/usr/local/oecore-x86_64/ in the present case).

Is that an expected behaviour (as the sdk is primarly designed to build applications) or can that be fixed during the sdk relocation ?

When you use the SDK, you need to be sure to source the SDK environment setup. Once you do that, pass to the compiler/linker the included CFLAGS and LDFLAGS as specified in that environment file.

They should end up passing at some point a --sysroot=... and that will tell gcc where the libraries and headers are for linking. Without the --sysroot= option, the compiler has no choice but to look for it's original compilation directory.

Hi Mark,

Quoted 10 lines · Mark Hatle

Quoted 5 lines · Eric Bénard

this can be fixed by installing the sdk to it's standard path (/usr/local/oecore-x86_64/ in the present case).

Is that an expected behaviour (as the sdk is primarly designed to build applications) or can that be fixed during the sdk relocation ?

When you use the SDK, you need to be sure to source the SDK environment setup. Once you do that, pass to the compiler/linker the included CFLAGS and LDFLAGS as specified in that environment file.

of course I did source it (and forget to put it in the email as that was obvious to me, sorry).

Quoted 4 lines

They should end up passing at some point a --sysroot=... and that will tell gcc where the libraries and headers are for linking. Without the --sysroot= option, the compiler has no choice but to look for it's original compilation directory.

true, that's why I provided the step to reproduce and said "as the sdk is primarly designed to build applications" and that's certainly why we get this problem : for linux & u-boot we can't use the LDFLAGS as set by the environment script else we get :

for u-boot :
arm-oe-linux-gnueabi-ld.bfd: unrecognized option '-Wl,-O1' so we need to pass LDFLAGS="" which then leads to :
arm-oe-linux-gnueabi-ld.bfd: cannot find -lgcc
if and only if the sdk was relocated.
(and I also get the error even if I add LDFLAGS=" --sysroot=/path_to/oecore-x86_64/sysroots/armv5te-oe-linux-gnueabi" so this seems specific to -lgcc)

for linux :
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
so here again we need to pass LDFLAGS="" which leads to a successful build as the build is not using lgcc.

Eric

I see, it's using ld instead of gcc for linking. AFAIK though, you really shouldn't be using -lgcc in either uboot or linux for any platform. That seems suspicious to me.