Re: Openembedded-devel Digest, Vol 43, Issue 99

Re: Openembedded-devel Digest, Vol 43, Issue 99

[Jay Snyder]

>
>
> The most easy way to turn it off is to not build with GNU HASH style, 
> This can
> be made by not using "--hash-style=SOMETHING" in the LDFLAGS.
>
> The GNU HASH is not a security mechanism but a dynamic linker 
> optimization to
> be able to resolve symbols faster.
>
> It was added later as the feature is not that old. Everything I do 
> build is
> building fine, so in case you see an "awful" lot of breakage it would 
> be nice
> if you could clarify this.
>
I'll post details next time I run into it.     Your solution above 
doesn't fix the problem, as the error the OE build system complaining 
about binaries NOT having the GNU Hash.      There are many packages 
that do not pass the "--hash-style" option from the bitbake configure 
task down to all their makefiles.    I'd have to go back through my 
local copies of recipes that I've patched to see which ones that I've 
had to do "CCFLAGS += ${LDFLAGS}" fix to.   In some cases, I needed to 
put patches in for Makefile.ac files.     Due to the current time crunch 
that I'm in on my current project, I will not have time for several 
weeks to go back through these changes.     It is my  intention to 
submit these patches for inclusion in OE when I have time (if someone 
else hasn't already).

Thank you,
Jay

Re: Openembedded-devel Digest, Vol 43, Issue 99

[Holger Hans Peter Freyther]

On Tuesday 23 February 2010 14:45:01 Jay Snyder wrote:

> 
> I'll post details next time I run into it.     Your solution above
> doesn't fix the problem, as the error the OE build system complaining
> about binaries NOT having the GNU Hash.

Why the need for capital letters? Take a look at the insane.bbclass, it will 
check if the target has the GNU hash only if --hash-style=gnu or --hash-
style=both is in the LDFLAGS (as seen from Bitbake). This means if you do not 
have --hash-style=* in your LDFLAGS, insane.bbclass will not test and it will 
not complain.

z.

How to build g++ to run on target?

[Jay Snyder]

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?

Thank you,
Jay Snyder

Re: How to build g++ to run on target?

[Khem Raj]

On Tue, Feb 23, 2010 at 5:51 AM, Jay Snyder
<jay.snyder@tycoelectronics.com> 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?

you already have built g++ when you bitbaked gcc recipe. You can look
under your ipk directory for the resulting package for g++
a recipe can build multiple packages

>
> Thank you,
> Jay Snyder
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Philip Balister]

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?

Philip


>
> Thank you,
> Jay Snyder
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Khem Raj]

On Tue, Feb 23, 2010 at 2:37 PM, Philip Balister <philip@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"

>
> Philip
>
>
>>
>> Thank you,
>> Jay Snyder
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Philip Balister]

On 02/23/2010 03:09 PM, Khem Raj wrote:
> On Tue, Feb 23, 2010 at 2:37 PM, Philip Balister<philip@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.

Philip

>
>>
>> Philip
>>
>>
>>>
>>> Thank you,
>>> Jay Snyder
>>>
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Tom Rini]

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

-- 
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation

Re: How to build g++ to run on target?

[Khem Raj]

On Tue, Feb 23, 2010 at 5:06 PM, Tom Rini <tom_rini@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@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.

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

>
> --
> Tom Rini <tom_rini@mentor.com>
> Mentor Graphics Corporation
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Denys Dmytriyenko]

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

Re: How to build g++ to run on target?

[Khem Raj]

On Tue, Feb 23, 2010 at 7:08 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> 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@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@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...

yes if I was to start fresh I would do it this way but as I said before OE uses
native to denote something else as of now. If we were to change conventions then
I would certainly use the more common naming as you mentioned.

>
>
>> to answer the original question I think RDEPEND was added for fixing
>> upgrade channels on existing systems.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: How to build g++ to run on target?

[Martyn Welch]

Tom Rini 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@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.
"target"?

-- 
Martyn Welch (Principal Software Engineer)   |   Registered in England and
GE Intelligent Platforms                     |   Wales (3828642) at 100
T +44(0)127322748                            |   Barbirolli Square, Manchester,
E martyn.welch@ge.com                        |   M2 3AB  VAT:GB 927559189