From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Issues with parallel build? (Was: gtk+native missing dep ?)
Date: Fri, 14 May 2010 17:04:25 -0700 [thread overview]
Message-ID: <1273881865.8005.205.camel@trini-m4400> (raw)
In-Reply-To: <AANLkTimDt7fVT14jNofov1ESwO2M_CvBAe6RsdvzZicE@mail.gmail.com>
On Fri, 2010-05-14 at 23:21 +0200, Andrea Adami wrote:
> > With DISTRO= ? I do most of my builds with 4 and haven't seen this.
> > But with a failure log on gtk+-native, figuring out the missing dep
> > shouldn't be too bad.
>
> FWIW distro is Angstrom, devel branch.
>
> DEPENDS_virtclass-native = "libpng-native atk-native pango-native
> cairo-native libxrender-native libxext-native"
>
> It's not a problem of missing deps, I suppose, because
>
> PARALLEL_MAKE = "-j5"
> #BB_NUMBER_THREADS = "4"
> BB_NUMBER_THREADS = "2"
> fixed the things. This time the dependencies were (correctly) built before.
Right. Lower number of threads means less stuff going on at once. I've
seen a lot of dep issues that only show up once you have a lot of
threads, or have packaged staging (which then marks off a lot of things
in the dep graph).
> Short resume:
>
> i repeatdly see (Angstrom) console-image failing *from scratch*
> because gtk+native do_compile errors out with:
>
> Cannot load module
> /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0/gtk+-2.20.0/modules/input/im-xim.la:
> /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0/gtk+-2.20.0/mo
> dules/input/.libs/im-xim.so: undefined symbol: g_realloc_n
> | /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0/gtk+-2.20.0/modules/input/im-xim.la
> does not export GTK+ IM module API:
> /oe/build/tmp/work/i686-linux/gtk+-native-2.20.0-r8.0
>
> g_realloc_n is defined in glib-2.0
>
> I've inspected the workdir and I've noticed "atk-native" and
> "pango-native" builds were not finished when gtk+-native broke.
> Both atk-native and pango-native (and cairo-native, which was built)
> have glib-2 as explicit dependency, so something seems wrong...
So, it really sounds like a bitbake bug. Doing a bitbake -e on gtk
+-native gives:
DEPENDS_virtclass-native="autoconf-native automake-native libtool-native
gnu-config-native coreutils-native libpng-native atk-native pango-native
cairo-native libxrender-native libxext-native"
DEPENDS="autoconf-native automake-native libtool-native
gnu-config-native coreutils-native libpng-native atk-native pango-native
cairo-native libxrender-native libxext-native"
So it's supposed to be waiting on all of that stuff, but it's not. And
I'm sure RP will need to know what version of bitbake you're using.
--
Tom Rini <tom_rini@mentor.com>
Mentor Graphics Corporation
next prev parent reply other threads:[~2010-05-15 0:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-14 17:47 Issues with parallel build? (Was: gtk+native missing dep ?) Andrea Adami
2010-05-14 17:55 ` Tom Rini
2010-05-14 21:21 ` Andrea Adami
2010-05-15 0:04 ` Tom Rini [this message]
2010-05-16 18:52 ` Richard Purdie
2010-05-19 22:57 ` Andrea Adami
2010-06-08 15:33 ` Andrea Adami
2010-10-20 3:33 ` Denys Dmytriyenko
2010-05-15 8:35 ` Michael Lippautz
2010-05-15 15:52 ` Andrea Adami
2010-05-14 22:12 ` Leon Woestenberg
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=1273881865.8005.205.camel@trini-m4400 \
--to=tom_rini@mentor.com \
--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.