invoking a native compiler (gcc)

invoking a native compiler (gcc)

[Trevor Woerner]

If a recipe needs to build some tool on the build machine which it later
wants to invoke, my understanding is that BUILD_CC should be used?

Re: invoking a native compiler (gcc)

[Robert Yang]

On 01/07/2016 01:21 PM, Trevor Woerner wrote:
> If a recipe needs to build some tool on the build machine which it later
> wants to invoke, my understanding is that BUILD_CC should be used?

Yes, you're right, use ${BUILD_CC}.

// Robert

>

Re: invoking a native compiler (gcc)

[Trevor Woerner]

Hi Robert,

On 01/07/16 03:07, Robert Yang wrote:
>
>
> On 01/07/2016 01:21 PM, Trevor Woerner wrote:
>> If a recipe needs to build some tool on the build machine which it later
>> wants to invoke, my understanding is that BUILD_CC should be used?
>
> Yes, you're right, use ${BUILD_CC}.
>

Ok, thanks. That's what I thought.

I was surprised to find that BUILD_CC is being set to whatever comes up
first in our build computer's PATH. But I guess the alternative would be
to make our builds longer by compiling our own native compiler for such
cases.

Re: invoking a native compiler (gcc)

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On 7 January 2016 at 15:40, Trevor Woerner <twoerner@gmail.com> wrote:

> I was surprised to find that BUILD_CC is being set to whatever comes up
> first in our build computer's PATH. But I guess the alternative would be
> to make our builds longer by compiling our own native compiler for such
> cases.
>

You could always set BUILD_CC to explicitly point to the right compiler on
your machine.  When I was trying to make OE work on Darwin I had to set
BUILD_CC to point at brew's gcc binaries.

Ross

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: invoking a native compiler (gcc)

[Richard Purdie]

On Thu, 2016-01-07 at 15:46 +0000, Burton, Ross wrote:
> 
> On 7 January 2016 at 15:40, Trevor Woerner <twoerner@gmail.com>
> wrote:
> > I was surprised to find that BUILD_CC is being set to whatever
> > comes up
> > first in our build computer's PATH. But I guess the alternative
> > would be
> > to make our builds longer by compiling our own native compiler for
> > such
> > cases.
> > 
> You could always set BUILD_CC to explicitly point to the right
> compiler on your machine.  When I was trying to make OE work on
> Darwin I had to set BUILD_CC to point at brew's gcc binaries.

Or you setup PATH to include things in the right order as we do with
other native tools...

Cheers,

Richard

Re: invoking a native compiler (gcc)

[Trevor Woerner]

On 01/07/16 11:37, Richard Purdie wrote:
> On Thu, 2016-01-07 at 15:46 +0000, Burton, Ross wrote:
>> On 7 January 2016 at 15:40, Trevor Woerner <twoerner@gmail.com>
>> wrote:
>>> I was surprised to find that BUILD_CC is being set to whatever
>>> comes up
>>> first in our build computer's PATH. But I guess the alternative
>>> would be
>>> to make our builds longer by compiling our own native compiler for
>>> such
>>> cases.
>>>
>> You could always set BUILD_CC to explicitly point to the right
>> compiler on your machine.  When I was trying to make OE work on
>> Darwin I had to set BUILD_CC to point at brew's gcc binaries.
> Or you setup PATH to include things in the right order as we do with
> other native tools...

I was surprised to learn that a compiler from the host machine was
potentially being used as part of a build, not which one is found and
being used. When I discovered this I was quite sure I had configured
something incorrectly. This is more of an academic exercise, I didn't
run into any problems.

I guess we're covered in the sense that each release specifies which
distros are supported. So as long as any native tools that are used in
each of the support distros are able to produce a successful build
everything should be fine. BUILD_CC is almost like an implicit
ASSUME_PROVIDED.

Re: invoking a native compiler (gcc)

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]


> On Jan 7, 2016, at 10:01 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> 
> 
> 
> On 01/07/16 11:37, Richard Purdie wrote:
>> On Thu, 2016-01-07 at 15:46 +0000, Burton, Ross wrote:
>>> On 7 January 2016 at 15:40, Trevor Woerner <twoerner@gmail.com>
>>> wrote:
>>>> I was surprised to find that BUILD_CC is being set to whatever
>>>> comes up
>>>> first in our build computer's PATH. But I guess the alternative
>>>> would be
>>>> to make our builds longer by compiling our own native compiler for
>>>> such
>>>> cases.
>>>> 
>>> You could always set BUILD_CC to explicitly point to the right
>>> compiler on your machine.  When I was trying to make OE work on
>>> Darwin I had to set BUILD_CC to point at brew's gcc binaries.
>> Or you setup PATH to include things in the right order as we do with
>> other native tools...
> 
> I was surprised to learn that a compiler from the host machine was
> potentially being used as part of a build, not which one is found and
> being used. When I discovered this I was quite sure I had configured
> something incorrectly. This is more of an academic exercise, I didn't
> run into any problems.
> 
> I guess we're covered in the sense that each release specifies which
> distros are supported. So as long as any native tools that are used in
> each of the support distros are able to produce a successful build
> everything should be fine. BUILD_CC is almost like an implicit
> ASSUME_PROVIDED.

It doesnt end at compiler.
We are cross compiling. so yes we do bootstrap using tools from build host.
you can go down the lane and start insulating from hosts by building native packages
for everything but it does not buy us much. We basically then end up building a build host distro ‘sort of’
before anything is built for target. We already are building too many things then
I would think we should. It also has a maintenance cost to build e..g OE packages to run on ubuntu
its an untested combination where as running ubuntu package on ubuntu is a tested combo



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]