Uninative and sstate

[Joshua Watt <jpewhacker@gmail.com>]

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?

Thanks,
Joshua Watt