Weird build dependency issue causing missing symbols

[Patrick Williams]

On Fri, Jul 03, 2020 at 12:18:34AM +0000, Ren, Zhikui wrote:
> Maybe the problem is that this header server.hpp is generated not  a source. 
> Artifact created from the same source *should* be the same (except timestamp)
> If the source did not update, just a forced rebuild to create new binaries,  I can see Yocto choose not to rebuild things depend on the package.
> In the case of boost, since it is devtool modified and the header is a source and not build artifact, it make sense to trigger all the rebuild. 
> 
> 
> -----Original Message-----
> From: openbmc <openbmc-bounces+zhikui.ren=intel.com at lists.ozlabs.org> On Behalf Of Bills, Jason M
> Sent: Thursday, July 2, 2020 5:00 PM
> To: openbmc at lists.ozlabs.org
> Subject: Re: Weird build dependency issue causing missing symbols
> 
> 
> 
> On 7/2/2020 2:33 PM, Patrick Williams wrote:
> > On Thu, Jul 02, 2020 at 12:58:43PM -0700, Bills, Jason M wrote:
> >> We have narrowed this down to being caused by two separate issues:
> >> 1. When phosphor-dbus-interfaces is rebuilt it will sometimes change 
> >> the order of the PropertiesVariant in server.hpp.
> > 
> > This sounds like a bug in sdbus++.  We should be sorting the variant 
> > parameters or issuing them in array order.  I'll look into it.
> > 
> >> 2. When the order of PropertiesVariant changes on a rebuild, the 
> >> recipes that already have an old copy of server.hpp are not triggered 
> >> to rebuild and are left with the old copy of server.hpp.
> > 
> > This isn't surprising if what is triggering the rebuild is not a Yocto 
> > variable change (or git revision).  Yocto doesn't cache the contents 
> > of the packages, but caches the variables that went into a build step.  
> > A hash of the variables are used to look up the potential 'sstate-cache'
> > files so that it can skip build steps.
> > 
> > If you think a variable or a git-revision should have changed with 
> > what you were doing, then maybe it is something else.
> > 
> It seems like a header file change should trigger a rebuild, though?  If I manually edited something like a library header file, I'd expect everything that includes that library to be rebuilt with the new header change.
> 
> I tried to devtool modify boost to check the behavior, but that causes boost to rebuild every time and correctly triggers the dependent builds. 
>   Maybe the case above of modifying a header file is invalid?

It doesn't matter what the content is: header, library, executable, data
file.  Yocto does not use contents in the decision of "does this need to
be rebuilt".  It only uses variables from recipes.  If the variables do
not change, the package is not rebuilt (unless explicitly tainted).

See https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#dev-invalidating-shared-state-to-force-a-task-to-run for example.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200703/9889b649/attachment.sig>