From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: chris@2net.co.uk
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>, yocto@yoctoproject.org
Subject: Re: gcc reports sysroot is /not/exist!
Date: Tue, 15 Sep 2015 10:45:54 +0100 [thread overview]
Message-ID: <1442310354.26666.50.camel@linuxfoundation.org> (raw)
In-Reply-To: <55F7E2E7.7050609@2net.co.uk>
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
next prev parent reply other threads:[~2015-09-15 9:46 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 [this message]
2015-09-15 14:09 ` Chris Simmonds
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=1442310354.26666.50.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=chris@2net.co.uk \
--cc=paul.eggleton@linux.intel.com \
--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.