On Oct 1, 2013, at 6:16 AM, Hans Beckérus <[email protected]> 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.
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
-Khem
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
