All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Simmonds <chris@2net.co.uk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>, yocto@yoctoproject.org
Subject: Re: gcc reports sysroot is /not/exist!
Date: Tue, 15 Sep 2015 15:09:30 +0100	[thread overview]
Message-ID: <55F8269A.4060705@2net.co.uk> (raw)
In-Reply-To: <1442310354.26666.50.camel@linuxfoundation.org>

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.


  reply	other threads:[~2015-09-15 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15  8:48 gcc reports sysroot is /not/exist! Chris Simmonds
2015-09-15  8:58 ` Paul Eggleton
2015-09-15  9:20   ` Chris Simmonds
2015-09-15  9:45     ` Richard Purdie
2015-09-15 14:09       ` Chris Simmonds [this message]
2015-09-15 17:22         ` Robert Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55F8269A.4060705@2net.co.uk \
    --to=chris@2net.co.uk \
    --cc=paul.eggleton@linux.intel.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.