All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcin Juszkiewicz <openembedded@hrw.one.pl>
To: openembedded-devel@lists.openembedded.org
Cc: angstrom-distro-devel@linuxtogo.org
Subject: Results of my mass build of all OE targets for Angstrom
Date: Wed, 3 Jan 2007 14:25:00 +0100	[thread overview]
Message-ID: <200701031425.00509.openembedded@hrw.one.pl> (raw)


Before X-mas break I started one big build running on build machine offered 
to me by CELF. It was build of 'task-base' (ALL machines) 
and 'bootstrap-image' (most of machines - building them now) for ALL OE 
machines and Angstrom-2007.1 distribution.

Script used was:

for machine in $OEDIR/conf/machine/*.conf
do 
	MACHINE=`basename $machine .conf` 
	echo $MACHINE 
	echo "MACHINE='$MACHINE'" >conf/auto.conf
	bitbake task-base
	echo $MACHINE
done

Some of problems which I got are related to staging changes which were done 
during that time (working copy of repository was updated periodically). 

Build is still progressing...

===

I got 'task-base' built for 31 target devices: a780, akita, amsdelta, c7x0, 
ep93xx, epia, gumstix, h1940, h2200, h4000, h5000, h6300, hx4700, 
ixp4xxle, ks8695, logicpd-pxa270, magician, mainstone, mx21ads, mx31ads, 
native, navman-icn330, netbook-pro, nokia770, omap5912osk, poodle, 
progear, qemuarm, spitz, tosa, wrap.

===

Those machines got 'bootstrap-image' already built: a780, akita, amsdelta, 
c7x0, ep93xx, epia, h2200, h4000, h5000, hx4700, logicpd-pxa270, magician, 
mainstone, mx21ads, mx31ads, native, navman-icn330, netbook-pro, nokia770, 
omap5912osk, poodle, progear.

I will build rest by hand.

===

Few targets use 2.4 kernels so they can not be supported by Angstrom (2.6 
is needed), some (colinux, geodelx) use old 2.6.10/11 ones which failed to 
build with Angstrom toolchain:

{standard input}: Assembler messages:
{standard input}:1443: Error: suffix or operands invalid for `mov'
{standard input}:1445: Error: suffix or operands invalid for `mov'
{standard input}:1754: Error: suffix or operands invalid for `mov'
{standard input}:1756: Error: suffix or operands invalid for `mov'
{standard input}:1860: Error: suffix or operands invalid for `mov'
{standard input}:1861: Error: suffix or operands invalid for `mov'
{standard input}:1981: Error: suffix or operands invalid for `mov'
{standard input}:1983: Error: suffix or operands invalid for `mov'
{standard input}:2127: Error: suffix or operands invalid for `mov'
{standard input}:2140: Error: suffix or operands invalid for `mov'
  CC      mm/filemap.o
make[1]: *** [arch/i386/kernel/process.o] Error 1

Some machines lack kernel config at all: omap1710h3, omap2420h4 (bugs 
filled). 

Kernel for 'devkitidp-pxa255' is unfetchable but Cliff Brake has fixing 
this in queue.

===

MIPSel architecture need populating site/ files to get dbus-glib or strace 
built. This can be done by creating site/common-glibc and 
site/common-uclibc files which would be used by all archs - 
siteinfo.bbclass is already prepared for it.

===

Another problematic architecture is SPARC with sun4cdm machine. This one 
fails on glibc-initial:

checking size of long double... (cached) 8
running configure fragment for sysdeps/sparc/sparc32/elf
checking for sparc32 TLS support... no
checking for sparc32 ld WDISP22 handling... unknown
running configure fragment for sysdeps/ieee754/ldbl-opt
checking whether 
gcc  -I/a/home/hrw/devel/build/test/tmp/staging/sparc-angstrom-linux/include -fexpensive-optimizations -fomit-fram
e-pointer -frename-registers -Os supports -mlong-double-128... no
configure: error: this configuration requires -mlong-double-128 support

===

ipkg-make-index is very slow when deploy/ipk contain lots of packages. In 
my build I got 675,858,558 bytes in 22074 files so most of time spent on 
generating image was spent in regenerating index file. I think that 
splitting deploy/ipk into archs and using them for creating images can 
speedup this process.

IIRC someone had a version of i-m-i which was few times faster - why we do 
not use it?

===

Some statistics: build took about 10 days but had some hangups which I had 
to solve by hand - for example I forgot to set PATCH_RESOLVER = "noop" so 
some builds failed on not-applying patches. Space used is about 80 
gigabytes (running du -h takes too much time to check).

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

       We're here to give you a computer, not a religion.
       		-- Bob Pariseau, at the introduction of the Amiga





             reply	other threads:[~2007-01-03 13:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-03 13:25 Marcin Juszkiewicz [this message]
2007-01-03 16:46 ` [Angstrom-devel] Results of my mass build of all OE targets for Angstrom Koen Kooi
2007-01-04  0:10   ` Alban J Pearce
2007-01-05 13:45     ` José Bernardo Bandos Rodrigues
2007-01-06  8:42       ` GoXbox Live

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200701031425.00509.openembedded@hrw.one.pl \
    --to=openembedded@hrw.one.pl \
    --cc=angstrom-distro-devel@linuxtogo.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.