[yocto] Problem finding -lgcc when using SDK toolchain

Khem Raj raj.khem at gmail.com
Tue Oct 1 23:13:57 PDT 2013


On Oct 1, 2013, at 11:03 AM, Hans Beckerus <hans.beckerus at gmail.com> wrote:

> On 2013-10-01 7:35, Khem Raj wrote:
>> On Oct 1, 2013, at 6:16 AM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>> 
>>> Hello. We have stumbled into a problem when using ld directly instead
>>> of going through the gcc frontend.
>>> A simple operation like this fails:
>>> 
>>>> ${CC} -c hello_world.c
>>>> ${LD} hello_world.o -lgcc
>>> arm-poky-linux-gnueabi-ld: cannot find -lgcc
>>> 
>>> And yes, I know -lgcc is not required in this case to compile this
>>> one, but this is only a simple reproducer.
>>> The real issue was discovered when trying to build U-Boot from the SDK.
>>> 
>>> To resolve this problem we are forced to provide
>>> -L<sysroot>/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
>>> But that should not be needed, should it? Anyone else bumped into this
>>> problem? Are there any "real" solutions.
>>> I am starting to think it has to do with the hardcoded installation
>>> path in the binaries maybe?
>> I doubt that infact we try hard to keep it relocatable. The problem is you are interpreting
>> --sysroot option to do more than what its supposed to do. when linking it only affects INPUT,  GROUP
>> and SEARCH_DIR linker script variables and if you look at the linker script path to libgcc is not
>> specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out where the right libgcc is installed
>> and sometimes when you have complex multilib environments thats very handy. linker does not know
>> anything about libgcc its just another library for it.
> Hi Khem, thanks for your time. I am sure I put too much value into --sysroot, but what still strikes me a bit odd is why the simple reproducer I showed before works just fine using the local host gcc and ld? It seems to have no issues in finding libgcc.a?

Does it ? what distro are you using on build host. gcc -c hello.c;ld hello.o -lgcc , does that work ?
on my Ubuntu based system it fails exact same way as OE SDK, and for the reasons I described
if you use bare ld to do linking then you can not assume it to resolve all kind of environment for you
gcc driver is there for a reason.

> So what you are saying is that it is actually expected that U-Boot build will fail when compiled through the SDK toolchain directly without adding additional options to the linker? Is that also what the u-boot recipe is doing? After all, it works fine to bitbake u-boot.

No, the magic is in u-boot itself see in top level Makefile


PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc



> 
>> however you could do  something like
>> 
>> ${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
>> 
>> to get to the library
>> 
>> and specify that in your linker cmdline
> Ok, guess it will simply give me the same path as we are currently hardcoding, but if the toolchain moves your solution is definitely to prefer.
> Thanks for the tip. Did only not know about the --print-sysroot command until now.
>> -Khem
> 




More information about the yocto mailing list