Re: [oe] RFC: Support for R/W git in bitbake

[Antonio Ospite]

On Wed, 18 Apr 2012 03:34:27 +0200
Ulf Samuelsson  wrote:

> On 2012-04-18 01:07, Paul Eggleton wrote:
> > On Wednesday 18 April 2012 00:35:29 Ulf Samuelsson wrote:
> >> Today bitbake supports read only git access in recipes.
> >> For various reasons, I would like to be able to do recipes
> >> which would check out in a read/write mode.
> > Could you elaborate on "various reasons"?
> >
> > Would the new externalsrc bbclass be useful in your case?
> >
> > Cheers,
> > Paul
> >
> 
> 1. If I am busy working on an application, then it simplifies the 
> development process.
>  I can modify the code in the tree and push.
>  This is mainly for kernel development.
>

for that you can pass "protocol=file" to make the git fetcher use the
"file" transport, see

http://ao2.it/en/blog/2010/05/27/neat-compilerun-cycle-git-and-openembedded

basically, in the .bb recipe, you can fetch from a local clone where
you do your normal work.

> 2. If I work on a prerelease of some S/W drivers/Applications under NDA,
>  then I cannot make that code publicly available
>  but I still want to put  that on my Internet accessible git server.
>  Typicailly this is before the release of a new chip and info about 
> the chip should not be
>  made public before the chip is released.
> 
> 3.  I want to be able to ship something similar to the Angstrom setup 
> scripts
>   to someone else, and have them build an image, but it should not 
> be available
>   to anyone not accepted (without public key at the git server).
>

maybe you can pass "protocol=ssh" as well to the git fetcher as well,
but I haven't tried that, when you say "R/W mode" you are basically
saying "ssh transport" for git, right? Let us know if that works.

> There are other uses for such a functionality, but those are my 
> immediate needs.
> 
> As you see, this is mostly for development.
> Once the code is released, then the recipe would be changed to the 
> normal git access.
> 
> Didn't know anything about the externalsrc bbclass, but after checking, 
> I would say no.
> It won't do the two things above. I do see the use of it though.
>

Ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?


pgpA6PWyQul2Q.pgp
Description: PGP signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 10:30 PM, Khem Raj wrote:

On Tue, Apr 17, 2012 at 5:37 PM, j  wrote:

Well finally caught what I think is the package the segfault kicks on expat.
Though not sure what I should look for to be able to sort it out but will
see where I get.

Though I still get the gcc and bash messages in the QA log. If anyone is
willing to share some info on what or how I can figure out how to find what
causes the segfault in the recipe or if I am even catching the correct one.


you are not giving out enough information. Looking at dmesg is not
going to give much info
if ld segfaults which I assume is cross ld here then the corresponding
recipe should fail
and then you should look in the build of that package and the commands
causing the segfaults
should be in log.do_compile or log.do_install.

Thanks
-Khem

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
See thats the thing no recipe is failing but the system segfaults. The 
resulting images have had quirks which is what led me to trying to sort 
out the segfault issue.


Sorry to sound so dumb but if there is no recipe failing and 2 separate 
systems are segfaulting in similar manners and both result with not 
fully functioning images/packages where else can I look for info? I 
posted all the logs to one of the builds, and the QA log seems to be the 
only thing really spitting out anything. I am open to trying and or 
sharing any and all relevant info to help sort it out or get me on track 
to sorting it out.


Thank you for all the continued effort.

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[Khem Raj]

On Tue, Apr 17, 2012 at 5:37 PM, j  wrote:
> Well finally caught what I think is the package the segfault kicks on expat.
> Though not sure what I should look for to be able to sort it out but will
> see where I get.
>
> Though I still get the gcc and bash messages in the QA log. If anyone is
> willing to share some info on what or how I can figure out how to find what
> causes the segfault in the recipe or if I am even catching the correct one.
>

you are not giving out enough information. Looking at dmesg is not
going to give much info
if ld segfaults which I assume is cross ld here then the corresponding
recipe should fail
and then you should look in the build of that package and the commands
causing the segfaults
should be in log.do_compile or log.do_install.

Thanks
-Khem

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] RFC: Support for R/W git in bitbake

[Ulf Samuelsson]

On 2012-04-18 01:07, Paul Eggleton wrote:

On Wednesday 18 April 2012 00:35:29 Ulf Samuelsson wrote:

Today bitbake supports read only git access in recipes.
For various reasons, I would like to be able to do recipes
which would check out in a read/write mode.

Could you elaborate on "various reasons"?

Would the new externalsrc bbclass be useful in your case?

Cheers,
Paul



1. If I am busy working on an application, then it simplifies the 
development process.

I can modify the code in the tree and push.
This is mainly for kernel development.

2. If I work on a prerelease of some S/W drivers/Applications under NDA,
then I cannot make that code publicly available
but I still want to put  that on my Internet accessible git server.
Typicailly this is before the release of a new chip and info about 
the chip should not be

made public before the chip is released.

3.  I want to be able to ship something similar to the Angstrom setup 
scripts
 to someone else, and have them build an image, but it should not 
be available

 to anyone not accepted (without public key at the git server).

There are other uses for such a functionality, but those are my 
immediate needs.


As you see, this is mostly for development.
Once the code is released, then the recipe would be changed to the 
normal git access.


Didn't know anything about the externalsrc bbclass, but after checking, 
I would say no.

It won't do the two things above. I do see the use of it though.


--
Best Regards
Ulf Samuelsson
u...@emagii.com
+46 722 427437


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 02:16 PM, j wrote:

On 04/17/2012 01:17 PM, j wrote:

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




 





I went for a build on the borrowed machine again but this time I 
did not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are 
no QA

logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on 
the

laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with 
no X

running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a 
task?


--Mark
Not that I can tell, but that does not mean it is not (still 
learning things), but possible one of threads is working on 
something perl related when it happens and I am not seeing it or 
realizing it. If you are willing to post the commands I could run to 
check, I can post the results. But when I do just a bitbake -c 
compile perl on a clean build dir all I would see was the segfault 
in dmesg and the results in QA log. Nothing would show up on the 
command line that was not in the QA log, after doing each step one 
by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and 
perl, will post the results after. But looks promising for my laptop 
so far as no segfaults yet. Borrowed machine is on to building the 
kernel now and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that 
is expected not the nvidia's supplied version. So maybe that is not 
fully it. But still all seems related to being in an X environment 
for me when building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.


My borrowed machine segfaulted while finishing building perl. So I 
guess that had nothing to do with the segfault issues. I ended up with 
the same qa.log output and same type of output on dmesg relating to 
libc and ld again.


Laptop no X on that segfaulted in the normal places

Should I try installing Ubuntu 10.04 on the borrowed machine and 
seeing if the OS works on that machine? I am still lost as nothing 
seems to really be telling me what is segfaulting. The rest of the 
logs basically look the same as the series I posted earlier.




Well finally caught what I think is the package the segfault kicks on 
expat. Though not sure what I should look for to be able to sort it out 
but will see where I get.


Though I still get the gcc and bash messages in the QA log. If anyone is 
willing to share some info on what or how I can figure out how to find 
what causes the segfault in the recipe or if I am even catching the 
correct one.


Thank you

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] RFC: Support for R/W git in bitbake

[Paul Eggleton]

On Wednesday 18 April 2012 00:35:29 Ulf Samuelsson wrote:
> Today bitbake supports read only git access in recipes.
> For various reasons, I would like to be able to do recipes
> which would check out in a read/write mode.

Could you elaborate on "various reasons"?

Would the new externalsrc bbclass be useful in your case?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] RFC: Support for R/W git in bitbake

[Ulf Samuelsson]

Today bitbake supports read only git access in recipes.
For various reasons, I would like to be able to do recipes
which would check out in a read/write mode.

I.E: have bitbake do "git clone g...@emagii.com:myproject"

Did a prototype extension to bitbake that assumes the following URI
wgit://emagii.com/myproject

Any objections to such an extension?
Suggestions for an alternative implementation?

--
Best Regards
Ulf Samuelsson
u...@emagii.com



___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 01:17 PM, j wrote:

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




 





I went for a build on the borrowed machine again but this time I 
did not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a 
task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If 
you are willing to post the commands I could run to check, I can post 
the results. But when I do just a bitbake -c compile perl on a clean 
build dir all I would see was the segfault in dmesg and the results 
in QA log. Nothing would show up on the command line that was not in 
the QA log, after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and 
perl, will post the results after. But looks promising for my laptop 
so far as no segfaults yet. Borrowed machine is on to building the 
kernel now and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that 
is expected not the nvidia's supplied version. So maybe that is not 
fully it. But still all seems related to being in an X environment for 
me when building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.


My borrowed machine segfaulted while finishing building perl. So I guess 
that had nothing to do with the segfault issues. I ended up with the 
same qa.log output and same type of output on dmesg relating to libc and 
ld again.


Laptop no X on that segfaulted in the normal places

Should I try installing Ubuntu 10.04 on the borrowed machine and seeing 
if the OS works on that machine? I am still lost as nothing seems to 
really be telling me what is segfaulting. The rest of the logs basically 
look the same as the series I posted earlier.



___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [yocto] meta-chromium

[Denys Dmytriyenko]

On Tue, Apr 17, 2012 at 10:40:28PM +0200, Eric B?nard wrote:
> Hi,
> 
> we have pushed the begining of our (Eukr?a Electromatique's team and
> especially Denis) work to get Chromium to build with OpenEmbedded Core
> to : git://github.com/eukrea/meta-chromium.git
> https://github.com/eukrea/meta-chromium
> 
> For the moment it's only tested on ARMv7 platforms (i.MX515 and i.MX535
> based) where it seems robust and quite fast on most of the HTML5 tests
> we ran (only WebGL doesn't yet work).
> 
> Feel free to send patches to improve the recipes and add support for
> other platforms.
> 
> TODO :
> - enable WebGL with OpenGL ES support
> - support other platforms than armv7
> - merge with meta-mozilla to create a meta-browser layer

Eric, Denis,

Great news! Thanks for your work!

-- 
Denys


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] meta-chromium

[Paul Eggleton]

On Tuesday 17 April 2012 13:44:00 Khem Raj wrote:
> On Tue, Apr 17, 2012 at 1:40 PM, Eric Bénard  wrote:
> > we have pushed the begining of our (Eukréa Electromatique's team and
> > especially Denis) work to get Chromium to build with OpenEmbedded Core
> > to : git://github.com/eukrea/meta-chromium.git
> > https://github.com/eukrea/meta-chromium
> 
> good job Eric and Denis can you add an entry into  layerindex too please
> if you havent done that already
> 
> http://openembedded.org/LayerIndex

I just did ;)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] meta-chromium

[Khem Raj]

On Tue, Apr 17, 2012 at 1:40 PM, Eric Bénard  wrote:
>
>
> we have pushed the begining of our (Eukréa Electromatique's team and
> especially Denis) work to get Chromium to build with OpenEmbedded Core
> to : git://github.com/eukrea/meta-chromium.git
> https://github.com/eukrea/meta-chromium

good job Eric and Denis can you add an entry into  layerindex too please
if you havent done that already

http://openembedded.org/LayerIndex

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] meta-chromium

[Eric Bénard]

Hi,

we have pushed the begining of our (Eukréa Electromatique's team and
especially Denis) work to get Chromium to build with OpenEmbedded Core
to : git://github.com/eukrea/meta-chromium.git
https://github.com/eukrea/meta-chromium

For the moment it's only tested on ARMv7 platforms (i.MX515 and i.MX535
based) where it seems robust and quite fast on most of the HTML5 tests
we ran (only WebGL doesn't yet work).

Feel free to send patches to improve the recipes and add support for
other platforms.

TODO :
- enable WebGL with OpenGL ES support
- support other platforms than armv7
- merge with meta-mozilla to create a meta-browser layer

Eric

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




 





I went for a build on the borrowed machine again but this time I did 
not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If you 
are willing to post the commands I could run to check, I can post the 
results. But when I do just a bitbake -c compile perl on a clean build 
dir all I would see was the segfault in dmesg and the results in QA 
log. Nothing would show up on the command line that was not in the QA 
log, after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and perl, 
will post the results after. But looks promising for my laptop so far 
as no segfaults yet. Borrowed machine is on to building the kernel now 
and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that is 
expected not the nvidia's supplied version. So maybe that is not fully 
it. But still all seems related to being in an X environment for me when 
building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:









I went for a build on the borrowed machine again but this time I did not
go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If you 
are willing to post the commands I could run to check, I can post the 
results. But when I do just a bitbake -c compile perl on a clean build 
dir all I would see was the segfault in dmesg and the results in QA log. 
Nothing would show up on the command line that was not in the QA log, 
after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and perl, 
will post the results after. But looks promising for my laptop so far as 
no segfaults yet. Borrowed machine is on to building the kernel now and 
nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.




___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[Mark Hatle]

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




 





I went for a build on the borrowed machine again but this time I did not
go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is something in 
perl (or elsewhere) trying to run qemu to finish up a task?


--Mark


Thank you
___
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: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 09:13 AM, J. L. wrote:









I went for a build on the borrowed machine again but this time I did not 
go into X just stayed in RL3. Then ran bitbake perl, on a clean build 
dir. It is just about to finish building a few steps away but where I 
normally get the segfaults, it has not spit those out. There are no QA 
logs being generated either. So looks like it had/has something to do 
with running X, both systems are running nvidia graphics cards. The 
laptop has a new mobile one, borrowed an old one that is nouveau 
compatible. So both open and closed nvidia drivers were tried. But 
something when in the graphical environment is giving the segfault 
issues I have been seeing. I have not yet verified if killing X on the 
laptop builds and eliminates the issues as well.


Will post back once I have built the kernel on both machines with no X 
running.


Thank you
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [oe-core] ld segfault cant figure it out

[J. L.]

I forgot to note angstrom version being used
DISTRO   = "angstrom-2010.x"


On Tue, Apr 17, 2012 at 8:54 AM, Gary Thomas  wrote:

> On 2012-04-17 09:41, J. L. wrote:
>
>> Well I borrowed a tower from a friend setup everything on a fresh install
>> for both OS and build environment. Well I am still getting the same issue
>> so it must not be an actual hardware issue. The first was trying to be
>> built on my laptop, now trying this tower I get the same results just
>> starting from scratch and building perl.
>>
>
> What are your exact details - OS & Angstrom (versions, etc).  I'll try
> and run the same process here if you'll send enough details to reproduce
> exactly what you've done (which should be straight forward to provide since
> you just [re]did it yourself).
>
>
>> I tried building just gcc and bash and well after cleaning them and I am
>> not seeing anything that sticks out to me. Other than the errors and what
>> not.
>>
>> Can anyone help me figure this out. Since it is now for sure not a
>> hardware
>> issue, die to same results on 2 machines. I have attached the cooker logs
>> and qalogs incase they could be of any use in helping figure out the
>> issue.
>>
>> Thank your for your time and help
>>
>>
>> QALOG
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc_eh.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcov.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc.a'
>> bash-4.2: bash: Found a reference to /usr/ in
>> /home/gooms/OE/setup-scripts/**build/tmp-angstrom_2010_x-**
>> eglibc/work/armv7a-angstrom-**linux-gnueabi/bash-4.2-r2/**
>> packages-split/bash/bin/**bashbug
>> bash-4.2: Shell scripts in base_bindir and base_sbindir should not
>> reference anything in exec_prefix
>>
>>
>> SEGFAULT
>> [10582.729446] ld[24926]: segfault at 8 ip b75ba427 sp bff61970 error 4 in
>> libc-2.15.so[b7576000+19b000]
>> [10596.912141] ld[30317]: segfault at 8 ip b758e427 sp bfbac350 error 4 in
>> libc-2.15.so[b754a000+19b000]
>>
>>
>> On Mon, Apr 16, 2012 at 6:43 PM, j  wrote:
>>
>>  On 04/16/2012 03:34 PM, j wrote:
>>>
>>>  On 04/16/2012 03:28 PM, Gary Thomas wrote:

  On 2012-04-16 16:11, j wrote:
>
>  On 04/13/2012 03:50 PM, j wrote:
>>
>>  On 04/13/2012 03:46 PM, j wrote:
>>>
>>>  There seems to be a couple of packages when I build that cause ld
 segfaults such as
 [ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c
 error
 4 in libc-2.13.so[73d000+15c000]
 [ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc
 error
 4 in libc-2.13.so[b64000+15c000]

 I can not seem to be able to track down the package/packages that
 are
 causing this. I have tried with a clean build dir and only building
 nano
 and I get it so it is something in
 the getting environment ready steps. Is there a way I can easily
 track down the build/builds that are causing this? Am I even on the
 right
 track in this thinking? Nothing fails
 to build and other than task-native-sdk all result in what seem to
 be
 working packages.

 Any info on what or how to figure it out would be greatly
 appreciated.
 building for bbxm on 11.04(uptodate), build environment setup with
 Angstrom scripts and all is up to date.

 Thank you

  Sorry forgot the info from qa.log
>>>
>>> libgcc-4.5: non -staticdev package contains static .a library:
>>> libgcc-dev path
>>> '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+**
>>> svnr184907/packages-split/libgcc-dev/usr/lib/arm-**
>>> angstrom-linux-gnueabi/4.5.4/libgcc.a'
>>>
>>> libgcc-4.5: non -staticdev package contains static .a library:
>>> libgcc-dev path
>>> '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+**
>>> svnr184907/packages-split/libgcc-dev/usr/lib/arm-**
>>> angstrom-linux-gnueabi/4.5.4/libgcov.a'
>>>
>>> libgcc-4.5: non -staticdev package contains static .a library:
>>> libgcc-dev path
>>> '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+**
>>> svnr184907/packages-split/libgcc-dev/usr/lib/arm-**
>>> angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
>>>
>>> bash-4.2: bash: Found a reference to /usr/ in
>>> /home/beagle/OE/

Re: [oe] [oe-core] ld segfault cant figure it out

[J. L.]

OS - Arch Linux i686 fully up to date, Kernel's tried 3.3.1 3.0.27

Build machines: 1. Toshiba qosmio x505-887 laptop
2. Dell XPS tower
I can give exact hardware specs if needed.

Setup how Angstrom site says to for their build environment setup secripts.
Packages installed are all on OE and your distro plus I was also missing
cpio.

OE Build Configuration:
BB_VERSION= "1.15.1"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "beagleboard"
DISTRO= "angstrom"
DISTRO_VERSION= "v2012.04-core"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU= "vfp-neon"

Once the environment is setup, I source my environment file then I just run
bitbake perl
or
bitbake virtual/kernel

both give the segfaults. It appears the segfaults happen during teh build
tools setup. Right around when bitbake pulls gcc into the line up to start
building.

That is all I have done each time.

If there is more info you need please let me know and I will gladly reply
with it.

I thank you emensly for your continued help with this Gary!!

JL

On Tue, Apr 17, 2012 at 8:54 AM, Gary Thomas  wrote:

> On 2012-04-17 09:41, J. L. wrote:
>
>> Well I borrowed a tower from a friend setup everything on a fresh install
>> for both OS and build environment. Well I am still getting the same issue
>> so it must not be an actual hardware issue. The first was trying to be
>> built on my laptop, now trying this tower I get the same results just
>> starting from scratch and building perl.
>>
>
> What are your exact details - OS & Angstrom (versions, etc).  I'll try
> and run the same process here if you'll send enough details to reproduce
> exactly what you've done (which should be straight forward to provide since
> you just [re]did it yourself).
>
>
>> I tried building just gcc and bash and well after cleaning them and I am
>> not seeing anything that sticks out to me. Other than the errors and what
>> not.
>>
>> Can anyone help me figure this out. Since it is now for sure not a
>> hardware
>> issue, die to same results on 2 machines. I have attached the cooker logs
>> and qalogs incase they could be of any use in helping figure out the
>> issue.
>>
>> Thank your for your time and help
>>
>>
>> QALOG
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc_eh.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcov.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc.a'
>> bash-4.2: bash: Found a reference to /usr/ in
>> /home/gooms/OE/setup-scripts/**build/tmp-angstrom_2010_x-**
>> eglibc/work/armv7a-angstrom-**linux-gnueabi/bash-4.2-r2/**
>> packages-split/bash/bin/**bashbug
>> bash-4.2: Shell scripts in base_bindir and base_sbindir should not
>> reference anything in exec_prefix
>>
>>
>> SEGFAULT
>> [10582.729446] ld[24926]: segfault at 8 ip b75ba427 sp bff61970 error 4 in
>> libc-2.15.so[b7576000+19b000]
>> [10596.912141] ld[30317]: segfault at 8 ip b758e427 sp bfbac350 error 4 in
>> libc-2.15.so[b754a000+19b000]
>>
>>
>> On Mon, Apr 16, 2012 at 6:43 PM, j  wrote:
>>
>>  On 04/16/2012 03:34 PM, j wrote:
>>>
>>>  On 04/16/2012 03:28 PM, Gary Thomas wrote:

  On 2012-04-16 16:11, j wrote:
>
>  On 04/13/2012 03:50 PM, j wrote:
>>
>>  On 04/13/2012 03:46 PM, j wrote:
>>>
>>>  There seems to be a couple of packages when I build that cause ld
 segfaults such as
 [ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c
 error
 4 in libc-2.13.so[73d000+15c000]
 [ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc
 error
 4 in libc-2.13.so[b64000+15c000]

 I can not seem to be able to track down the package/packages that
 are
 causing this. I have tried with a clean build dir and only building
 nano
 and I get it so it is something in
 the getting environment ready steps. Is there a way I can easily
 track down the build/builds that are causing this? Am I even on the
 right
 track in this thinking? Nothing fails
 to build and other than task-native-sdk all result in what seem to
 be
 working packages.

 Any info on what or how to figure it out would be greatly
 appreciated.
 building for bbxm on 11.04(uptodate), build environment setup with
 Angstrom scripts and all is up to date.

Re: [oe] [oe-core] ld segfault cant figure it out

[Gary Thomas]

On 2012-04-17 09:41, J. L. wrote:

Well I borrowed a tower from a friend setup everything on a fresh install
for both OS and build environment. Well I am still getting the same issue
so it must not be an actual hardware issue. The first was trying to be
built on my laptop, now trying this tower I get the same results just
starting from scratch and building perl.


What are your exact details - OS & Angstrom (versions, etc).  I'll try
and run the same process here if you'll send enough details to reproduce
exactly what you've done (which should be straight forward to provide since
you just [re]did it yourself).



I tried building just gcc and bash and well after cleaning them and I am
not seeing anything that sticks out to me. Other than the errors and what
not.

Can anyone help me figure this out. Since it is now for sure not a hardware
issue, die to same results on 2 machines. I have attached the cooker logs
and qalogs incase they could be of any use in helping figure out the issue.

Thank your for your time and help


QALOG
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a'
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a'
bash-4.2: bash: Found a reference to /usr/ in
/home/gooms/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug
bash-4.2: Shell scripts in base_bindir and base_sbindir should not
reference anything in exec_prefix


SEGFAULT
[10582.729446] ld[24926]: segfault at 8 ip b75ba427 sp bff61970 error 4 in
libc-2.15.so[b7576000+19b000]
[10596.912141] ld[30317]: segfault at 8 ip b758e427 sp bfbac350 error 4 in
libc-2.15.so[b754a000+19b000]


On Mon, Apr 16, 2012 at 6:43 PM, j  wrote:


On 04/16/2012 03:34 PM, j wrote:


On 04/16/2012 03:28 PM, Gary Thomas wrote:


On 2012-04-16 16:11, j wrote:


On 04/13/2012 03:50 PM, j wrote:


On 04/13/2012 03:46 PM, j wrote:


There seems to be a couple of packages when I build that cause ld
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c error
4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc error
4 in libc-2.13.so[b64000+15c000]

I can not seem to be able to track down the package/packages that are
causing this. I have tried with a clean build dir and only building nano
and I get it so it is something in
the getting environment ready steps. Is there a way I can easily
track down the build/builds that are causing this? Am I even on the right
track in this thinking? Nothing fails
to build and other than task-native-sdk all result in what seem to be
working packages.

Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with
Angstrom scripts and all is up to date.

Thank you


Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library:
libgcc-dev path
'/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
angstrom-linux-gnueabi/4.5.4/**libgcc.a'
libgcc-4.5: non -staticdev package contains static .a library:
libgcc-dev path
'/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
angstrom-linux-gnueabi/4.5.4/**libgcov.a'
libgcc-4.5: non -staticdev package contains static .a library:
libgcc-dev path
'/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
angstrom-linux-gnueabi/4.5.4/**libgcc_eh.a'
bash-4.2: bash: Found a reference to /usr/ in
/home/beagle/OE/setup-scripts/**build/tmp-angstrom_2010_x-**
eglibc/work/armv7a-angstrom-**linux-gnueabi/bash-4.2-r2/**
packages-split/bash/bin/**bashbug
bash-4.2: Shell scripts in base_bindir and base_sbindir should not
reference anything in exec_prefix

Any other places to check, as these I do not think relate to a
segfault?



I have now tried the build on 3 different OS's the most recent being
Arch. All give the same QA log's and all give me segfaults. That are all
basically close to the same errors
just differing libc versions.

I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is causing
the segfaults? Is it what is in the QA log?



Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+**197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f

Re: [oe] [OE-core] waning "it is recommended to set SYSTEMD_PACKAGES as -systemd"

[Koen Kooi]

Op 17 apr. 2012, om 17:39 heeft Martin Jansa het volgende geschreven:

> On Tue, Apr 17, 2012 at 05:22:31PM +0200, Andreas Oberritter wrote:
>> Hi,
>> 
>> the following warnings keep appearing on every fresh invocation of
>> bitbake since a few months, I think:
>> 
>> WARNING: .../meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb: it is 
>> recommended to set SYSTEMD_PACKAGES as -systemd
>> WARNING: .../meta-oe/recipes-connectivity/gateone/gateone_git.bb: it is 
>> recommended to set SYSTEMD_PACKAGES as -systemd

The above 2 only have systemd support, so the WARNING is completely bogus and 
should be silenced.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] waning "it is recommended to set SYSTEMD_PACKAGES as -systemd"

[Martin Jansa]

On Tue, Apr 17, 2012 at 05:22:31PM +0200, Andreas Oberritter wrote:
> Hi,
> 
> the following warnings keep appearing on every fresh invocation of
> bitbake since a few months, I think:
> 
> WARNING: .../meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb: it is recommended 
> to set SYSTEMD_PACKAGES as -systemd
> WARNING: .../meta-oe/recipes-connectivity/gateone/gateone_git.bb: it is 
> recommended to set SYSTEMD_PACKAGES as -systemd
> WARNING: .../meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb: it is 
> recommended to set SYSTEMD_PACKAGES as -systemd

yes they are there since systemd.bbclass rework, see
http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-February/038011.html
 
> Is anybody working on fixing them? Is anybody else also seeing them,
> or is this likely caused by some missing variable in my distro conf?

Not sure if someone is working on fixing them, but all is needed is to
add ${PN}-systemd subpackage and add it to tasks which expects to get
those apps with systemd support included.

> I am not using systemd.

It's pity that those are "parsing warnings" not QA warnings when
packaging it - so that only people building them would see them, maybe 
Andreas Müller will reply why it's checked while parsing.

I'm using systemd but not cloud9|gateone|lighttpd.

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [OE-core] waning "it is recommended to set SYSTEMD_PACKAGES as -systemd"

[Samuel Stirtzel]

2012/4/17 Andreas Oberritter :
> Hi,
>
> the following warnings keep appearing on every fresh invocation of
> bitbake since a few months, I think:
>
> WARNING: .../meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb: it is recommended 
> to set SYSTEMD_PACKAGES as -systemd
> WARNING: .../meta-oe/recipes-connectivity/gateone/gateone_git.bb: it is 
> recommended to set SYSTEMD_PACKAGES as -systemd
> WARNING: .../meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb: it is 
> recommended to set SYSTEMD_PACKAGES as -systemd
>
> Is anybody working on fixing them? Is anybody else also seeing them,
> or is this likely caused by some missing variable in my distro conf?
> I am not using systemd.

Hi,
these warnings get created at recipe parsing time regardless of
whether you are using Systemd or not,
so this is not a problem of your distro conf.

Don't know if anyone already has patches for them, but I see the warnings too.

>
> Regards,
> Andreas
>
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
Regards
Samuel

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] waning "it is recommended to set SYSTEMD_PACKAGES as -systemd"

[Andreas Oberritter]

Hi,

the following warnings keep appearing on every fresh invocation of
bitbake since a few months, I think:

WARNING: .../meta-oe/recipes-devtools/cloud9/cloud9_0.6.bb: it is recommended 
to set SYSTEMD_PACKAGES as -systemd
WARNING: .../meta-oe/recipes-connectivity/gateone/gateone_git.bb: it is 
recommended to set SYSTEMD_PACKAGES as -systemd
WARNING: .../meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb: it is 
recommended to set SYSTEMD_PACKAGES as -systemd

Is anybody working on fixing them? Is anybody else also seeing them,
or is this likely caused by some missing variable in my distro conf?
I am not using systemd.

Regards,
Andreas

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel