[OE-core] Feedback on building openembedded-core for qemuarm. Excerpts from buildlog

[Richard Purdie]

On Sat, 2011-11-26 at 13:38 +0100, Eric Bénard wrote:
> Hi Ulf,
> 
> Le 26/11/2011 12:24, Ulf Samuelsson a écrit :
> > 3. When I ran into this problem, I exited with ctrl-C.
> > This left some recipes in the middle of a fetch ,and the build could not
> > continue.
> > I had to "bitbake -c clean <package>" on all problematic packages to recover.
> > Seems a little bit fragile to me.
> >
> already met here : you must let bitbake end the other tasks already started to 
> prevent that (so only one control C).
> 
> > 4. linux-3.0 recipe in meta-ti does not build (On Ubuntu 11.10 x64).
> > Fails in the fetch stage.
> > I removed the layer, since it was not needed for qemuarm.
> >
> I also met this kind of problem. To prevent that problem, in my bsp overlay, I 
> always add COMPATIBLE_MACHINE = "" to the machine specific recipes.
> What is strange is that meta-ti also have this in its recipes so their 
> linux-3.0 recipe should not be used if you target qemuarm.
> 
> > 5. When compiling on a Ubuntu 11.10 x64 host (linux 3.x host)
> > tiff won't build.
> > Did:
> > bitbake console-image"
> > bitbake -c clean tiff
> > bitbake tiff
> > - No luck
> > Reading through the mailing list, I found someone which deleted
> > $TMPDIR and then
> > bitbake tiff
> > bitbake console-image
> > That worked for me as well once, second time, same problem.
> > Problem is that #include <iostream> fails.
> >
> > I noted that "iostream" is built and available in <sysroot>/usr/include/c++
> > On the host, it is located in /usr/incolude/c++/<version>
> > "tiff" build seems to be OK with Ubuntu 11.04 i686.
> >
> what is your BB_NUMBER_THREADS setting ?
> Here (on 2 different hosts/distro/arch but with an i7 CPU in both cases) if I 
> set it over 4, I often (always with a value of 8) meet problems with c++ 
> includes during build from scratch. 4 seems the magic value which never 
> trigger the problem.

To help me get further data points on this issue, are you using rm_work?
Do the recent changes in master help (the bitbake sstate/task_skip()
ones in particular)? I've not been able to reproduce this :(

Cheers,

Richard