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