[OE-core] libxslt populate_sysroot dependencies

[Slater, Joseph]

I've attached extracts from a very long log of a failure.  Turns out, it's not quite what I was expecting, but it does show the libxml2-native did not get to into sysroot before we tried to run xsltproc during the build of vala.

These failures are extremely rare, so I'll have to wait for another one to see if it's the same.  I realize that the build for libxml2 seems to have "hung", but I also think that letting libxslt put itself into sysroot before what it needs to run is in there is dangerous.

Anyway, there's no way in the world I could do the number of builds necessary to see if it's still an issue with the current bitbake, so I'll just watch for more failures here.

This has been kind of a waste of your time.  Thanks for looking at it.

Joe


> -----Original Message-----
> From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> Sent: Tuesday, April 08, 2014 2:34 PM
> To: Slater, Joseph
> Cc: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] libxslt populate_sysroot dependencies
> 
> On Tue, 2014-04-08 at 21:21 +0000, Slater, Joseph wrote:
> >
> > > -----Original Message-----
> > > From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> > > Sent: Tuesday, April 08, 2014 9:58 AM
> > > To: Slater, Joseph
> > > Cc: openembedded-core at lists.openembedded.org
> > > Subject: Re: [OE-core] libxslt populate_sysroot dependencies
> > >
> > > On Mon, 2014-04-07 at 23:25 +0000, Slater, Joseph wrote:
> > > > I have attached a patch that makes sure libxml2-native is available
> > > > when both it and libxslt-native
> > > > are taken from sstate.
> > > >
> > > > The patch parallels one from a few weeks ago for pixbufcache, but the
> > > > underlying problem might
> > > > have been fixed since then.  I looked for likely commits, and didn't
> > > > see anything, so this patch might still be needed.
> > >
> > > This is an shlibs depends, right? sstate should handle those correctly.
> > > If not, I'd like to see logs from a build where this doesn't happen on
> > > master please?
> >
> > The bitbake I was using is a bit out of date, so I cloned a poky repo today
> > and did several builds of vala-native pulling libxml2-native and libxslt-native
> > from sstate.
> >
> > I've attached the logs (truncated and annotated).  I think out_of_order.log shows that
> libxslt-native is
> > put in sysroot before libraries from libxml2 that it needs.
> >
> > The in_order.log shows what happens after applying the populate sysroot [depends] patch.
> >
> > I've attached the patch, too.
> 
> Thanks, I think I've been staring at too many builds for too long and
> have too many things cross threaded so I may have things confused,
> however I'm going to have a go at explaining this.
> 
> The setscene dependencies typically work backwards. The system does this
> deliberately since in general if you can install say bash
> do_package_write_ipk, we can skip the toolchain and other tools since we
> have the ipk we want. "bitbake <someimage> -c rootfs" is a good example
> of that in action, the -c build default tends to be a bit greedy.
> 
> The only time this reversal would cause a problem is for native/cross
> binaries *if* we execute them at setscene time. I know of two problem
> cases:
> 
> a) gdk-pixbuf does this to create a correct index file within the
>    sysroot.
> b) the adduser parts are used to setup user accounts before sstate
>    packages are extracted.
> 
> Those two cases have explicit setscene dependencies for those reasons. I
> am not aware of xlstproc being run at setscene time by anything so it
> doesn't need these dependencies.
> 
> Ok you say, what if it extracts libxslt-native but then fails to extract
> libxml2-native?
> 
> Well, when the main build happens, nothing with a dependency on
> libxsltproc will run until libxml2-native has been built.
> 
> So, your logs actually show what I would expect to happen, the question
> is what behaviour do you see which isn't correct?
> 
> Cheers,
> 
> Richard
> 
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log.txt
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140408/bed58223/attachment-0002.txt>