Weird build dependency issue causing missing symbols

[Bills, Jason M]

On 7/2/2020 10:20 PM, Patrick Williams wrote:
> 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.
> 
Thanks, Patrick! I think I get it.  I was stuck on the behavior that I 
see when I'm working with repo using 'devtool modify'.  I guess 'devtool 
modify' must have some additional magic to force rebuilds on file 
changes that doesn't apply to a standard build?