[oe] How to build g++ to run on target?

Denys Dmytriyenko denis at denix.org
Wed Feb 24 03:08:33 UTC 2010


On Tue, Feb 23, 2010 at 06:33:43PM -0800, Khem Raj wrote:
> On Tue, Feb 23, 2010 at 5:06 PM, Tom Rini <tom_rini at mentor.com> wrote:
> > On Tue, 2010-02-23 at 16:53 -0800, Philip Balister wrote:
> >>
> >> On 02/23/2010 03:09 PM, Khem Raj wrote:
> >> > On Tue, Feb 23, 2010 at 2:37 PM, Philip Balister<philip at balister.org>  wrote:
> >> >> On 02/23/2010 05:51 AM, Jay Snyder wrote:
> >> >>>
> >> >>> I was able to build gcc for installation directly onto the OE target
> >> >>> with "bitbake gcc". "bitbake g++" gives me "nothing provides g++".
> >> >>>
> >> >>> What is the magic bitbake command to provide this?
> >> >>
> >> >> bitbake task-sdk-native, and install task-native-sdk. Anyone know why the
> >> >> task creates a package with different name?
> >> >
> >> > may be because
> >> >
> >> > task-sdk-native.bb:RPROVIDES_${PN} = "task-native-sdk"
> >>
> >> I know that :) I am curious why the renaming.
> >
> > And if perhaps we couldn't get a different name altogether?  'native'
> > has a meaning normally that's not what it means here.
> > task-on-device-sdk is a bit wordy, but avoids 'native'.  Of course,
> > 'native development' also has a meaning too.. RPROVIDES perhaps?  Or is
> > that just the worst of both worlds..
> 
> yeah thats a good point. although native is not as bad but in context
> of OE we already
> assigned native to something that this task does not do. So using something like
> what you suggest or task-target-sdk would be nice.

Speaking of which, a collegue of mine was suggesting exactly the opposite - 
"native" should be used exactly for this type of naming, when it's native 
development (regardless of whether it's on a target or on a host), and OE's 
use of "native" is wrong and should be "host" instead, i.e. "pkgname-host" :)
I know it's a historical naming and cannot be changed easily...


> to answer the original question I think RDEPEND was added for fixing
> upgrade channels on existing systems.





More information about the Openembedded-devel mailing list