On Oct 1, 2013, at 11:03 AM, Hans Beckerus <[email protected]> wrote:
> On 2013-10-01 7:35, Khem Raj wrote: >> 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. > 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 [email protected] https://lists.yoctoproject.org/listinfo/yocto
