Re: Uninative and sstate

[Joshua Watt <jpewhacker@gmail.com>]

On Thu, 2018-01-04 at 22:00 +0000, Richard Purdie wrote:
> On Thu, 2018-01-04 at 14:15 -0600, Joshua Watt wrote:
> > We've run into a strange issued that turned out to be cased by
> > missing
> > iconv conversion libraries in our uninative tarball, but is sparked
> > a
> > larger question that I was hoping someone here could answer.
> > 
> > The problem was particularly baffling. We were attempting to use
> > Doxygen in a recipe which required some missing iconv conversion
> > files.
> > If we built doxygen locally, it worked just fine, but if we choose
> > to
> > allow bitbake to pull doxygen down from a sstate it would fail.
> > Even
> > more baffling, if we manually extracted the sstate
> > do_populate_sysroot
> > tarball for doxygen and used the executable there, everything
> > worked.
> > We surmised that bitbake was modifying the the doxygen executable
> > after
> > it extracted from the sstate tarball, which was confirmed by
> > comparing
> > checksums. After some digging, the cause of the change was tracked
> > down
> > to uninative_changeinterp() running after the sstate tarball was
> > extracted, changing the program interpreter to the one in the
> > uninative
> > tarball.
> > 
> > My question is: Why is this coercion of the program interpreter
> > *only*
> > done when the sysroot is populate from sstate? For consistency, it
> > would seem appropriate to also coerce the interpreter when doing
> > do_populate_sysroot from an actual build. If this had been done, we
> > would have noticed the missing library when building locally, and
> > the
> > sstate cache would not have caused "random" build breakage.
> > 
> > Does anyone have any insight as to why this isn't done?
> 
> Which release are you using?
> 
> There used to be an optimisation we made where we only did it when we
> needed to (using sstate). The move to RSS meant that we now always
> have
> to do it. I'd therefore guess you're using morty or older? On more
> recent versions you'll see it always relocating. There are pros and
> cons both ways.

Yes we are using morty. I suppose that at least explains the behavior.

Thanks for clarifying,
Joshua Watt

> 
> Cheers,
> 
> Richard