On Tue, 2015-09-15 at 10:20 +0100, Chris Simmonds wrote: > On 15/09/15 09:58, Paul Eggleton wrote: > > Hi Chris, > > > > On Tuesday 15 September 2015 09:48:34 Chris Simmonds wrote: > >> I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I > >> generate the it using the command: > >> > >> $ bitbake core-image-minimal -c populate_sdk > >> > >> Having installed the resulting SDK and sourced > >> /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi > >> > >> I find that the sysroot is not set: > >> > >> $ arm-poky-linux-gnueabi-gcc -print-sysroot > >> /not/exist > >> > >> This used to work fine in 1.7 and earlier. It looks like now I have to > >> use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many > >> Makefiles which set the compiler with something like > >> > >> CC=$(CROSS_COMPILE)gcc > >> > >> What to do? Why is gcc not configured with a sysroot any more? > > > > AIUI this had to be done in order to have a per-architecture compiler > > rather > > than a per-machine one. I believe if you use make -e then variables set in > > the > > environment will take precedence over those set in the makefile, which will > > allow the CC value set by the SDK's environment setup script to be used. > > > > (If we haven't documented this somewhere, we definitely ought to.) > > > > Cheers, > > Paul > > > > Well, that works as far as it goes, but it also overrides my CFLAGS, > LDFLAGS and so on, so I still have to change my Makefiles, of which > there are many. > > Also, I am not convinced this is a step in the right direction. I expect > to be able to compile a simple program using: > > $ gcc hello.c -o hello > > But with this new cross compiler setup, this happens: > > $ arm-poky-linux-gnueabi-gcc hello.c -o hello > hello.c:1:19: fatal error: stdio.h: No such file or directory > #include <stdio.h> > ^ > compilation terminated.
If we hardcode the path to the sysroot into the compiler, we hit several issues. Firstly, we rely on the relocation code within gcc to get this relocated correctly at install time. That doesn't work for the way we currently build the compilers so the default sysroot only works for the default installation directory. Yes, that one is fixable with some jumping through hoops. However if you don't want to set CFLAGS either, that implies we'd have to code the flags into the compiler as well. So we'd build a compiler per target sysroot and per set of optimisation flags for said target. That is grossly inefficient. We've always had the environment file there and we've always set CFLAGS this way, even in 1.7. If you used a non-default installation directory in 1.7, it likely didn't work properly without passing the right flags to gcc so you just go lucky even there. In 1.8, we poisoned the default sysroot, so we could clearly identify any software which wasn't using the CC and CFLAGS in ways we didn't expect. We did this to make our core builds deterministic. We decided to do the same with the SDK. If you really object to having to configure the compiler, I'd suggest creating some simple wrapper scripts which simply add in the sysroot and possibly other compiler flag options you need. The main reason we accepted doing the change to the defaults is that there is a comparatively simple workaround available for those that feel as you do. We could even have that code in the main repo, I've just felt so far that letting people see whats going on is better than hiding it behind more magic scripts. Cheers, Richard -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto