On Wed, Oct 2, 2013 at 8:13 AM, Khem Raj <raj.k...@gmail.com> wrote:
>
> On Oct 1, 2013, at 11:03 AM, Hans Beckerus <hans.becke...@gmail.com> wrote:
>
>> On 2013-10-01 7:35, Khem Raj wrote:
>>> On Oct 1, 2013, at 6:16 AM, Hans Beckérus <hans.becke...@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 ?
No, it does not. Whatever I tried before must have been wrong ;)
> 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
>
Ok, but here is were it fails! The above call gets resolved to "-L .",
and we do not have USE_PRIVATE_LIBGCC defined.
Doing ${CC} -print-libgcc-file-name shows the proper value. The reason
for this I now realize is that U-Boot does not pickup $CC from our
environment (which is including the --sysroot option). Without this
option -print-libgcc-file-name resolve to a simple file name without a
path. And thus dirname resolve it further to "." :(
So the fix for us is to do:
>make LDFLAGS="" CC="$CC"
Now it works.
I assume that is also what the U-Boot recipe is doing.
Thanks.
Hans
>
>
>>
>>> 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
>>
>
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
