gcc reports sysroot is /not/exist!

gcc reports sysroot is /not/exist!

[Chris Simmonds]

Hi,

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?

Chris Simmonds.

Re: gcc reports sysroot is /not/exist!

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: gcc reports sysroot is /not/exist!

[Chris Simmonds]

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.


Which violates the law of least astonishment.
Chris.

Re: gcc reports sysroot is /not/exist!

[Richard Purdie]

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

Re: gcc reports sysroot is /not/exist!

[Chris Simmonds]

Hi Richard,

On 15/09/15 10:45, Richard Purdie wrote:
> On Tue, 2015-09-15 at 10:20 +0100, Chris Simmonds wrote:
>>
>> 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.

I'll admit that is the model I had in mind. However, I can see that it
does not scale well if you are addressing a range of targets as Yocto
allows you to do. So it looks like it is time for me to update my modus
operandi to match. However, I'll bet that I am not the only one caught out.

> 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.
> 

No, I have no desire to write wrappers, I just wanted to clarify "the
right way to do things". Thank you very much for explaining it.

Chris.

Re: gcc reports sysroot is /not/exist!

[Robert Berger]

Hi,

I had a similar problem with you, but was able to fix it by replacing in
some global makefile:

CXX=${CROSS_COMPILE}g++
CC=${CROSS_COMPILE}gcc
LINKER=${CROSS_COMPILE}gcc
LOADER=${CROSS_COMPILE}ldd

with:

#CXX=${CROSS_COMPILE}g++
#CC=${CROSS_COMPILE}gcc
#LINKER=${CROSS_COMPILE}gcc
LINKER=$(CC)
#LOADER=${CROSS_COMPILE}ldd

Regards,

Robert
..."Whereas Europeans generally pronouce my name the right way (Ni-klows
Virt), Americans invariably mangle it into 'Nickle-less Worth'. This is
to say that Europeans call me by name, but Americans call me by value."
-- Niklaus Wirth

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1