Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Wed, Oct 2, 2013 at 8:13 AM, Khem Raj wrote:
>
> On Oct 1, 2013, at 11:03 AM, Hans Beckerus wrote:
>
>> On 2013-10-01 7:35, Khem Raj wrote:
>>> On Oct 1, 2013, at 6:16 AM, Hans Beckérus 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/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
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Oct 1, 2013, at 11:03 AM, Hans Beckerus wrote:
> On 2013-10-01 7:35, Khem Raj wrote:
>> On Oct 1, 2013, at 6:16 AM, Hans Beckérus 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/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
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On 2013-10-01 7:35, Khem Raj wrote:
> On Oct 1, 2013, at 6:16 AM, Hans Beckérus 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/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?
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.
> 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
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Oct 1, 2013, at 6:16 AM, Hans Beckérus 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/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
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem finding -lgcc when using SDK toolchain
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/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? If you choose not to install
the SDK where Yocto assumes it to be installed things break, even if
--sysroot is used.
Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
