Re: Issues with parallel build? (Was: gtk+native missing dep ?)

[Richard Purdie <rpurdie@rpsys.net>]

On Fri, 2010-05-14 at 17:04 -0700, Tom Rini wrote:
> On Fri, 2010-05-14 at 23:21 +0200, Andrea Adami wrote: 
> > 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.

There is insufficient evidence here to point at any one thing. I will
say that the threading dependency code has been around for a while and
most bugs like this turn out to be issues in the metadata, not bitbake.

When you say they were "not finished", what do you mean exactly?

Its normal they would still be packaging for example whilst gtk+ builds
since any dependency is on the populate_sysroot task of
pango-native/atk-native.

Cheers,

Richard