Re: [PATCH 1/1] pseudo: Fix problem related to realpath

[Mark Hatle <mark.hatle@windriver.com>]

On 6/10/11 10:14 AM, Mark Hatle wrote:
> On 6/10/11 10:02 AM, Paul Eggleton wrote:
>> On Thursday 09 June 2011 18:15:45 Mark Hatle wrote:
>>> --- a/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb
>>> +++ b/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb
>>> @@ -1,9 +1,10 @@
>>>  require pseudo.inc
>>>  
>>> -PR = "r0"
>>> +PR = "r1"
>>
>> I may be mistaken, but it seems to me that every time we need to rebuild 
>> pseudo it results in a race when an older version of pseudo is present. We 
>> handle building pseudo on its own first if it's not present, however if it just 
>> needs updating we go ahead and rebuild it at the same time as building other 
>> packages, and if it just happens that pseudo is needed when it's being built 
>> -> bang. At least that's my assumption given that since the last batch of 
>> updates, my rebuild of perl-native failed at the same time as pseudo's 
>> do_compile with a large number of "ERROR: ld.so: object 'libpseudo.so' from 
>> LD_PRELOAD cannot be preloaded: ignored" messages.
>>
>> Am I right in that there's currently no mechanism to work around this?
>>
>> Cheers,
>> Paul
>>
> 
> Theoretically updating pseudo shouldn't happen very often.  But yes, currently
> there is an issue that pseudo updates are not caused and cause the pseudo

Wow, too early in the morning I guess..  let me translate that for people who
are awake...

... there is an issue that pseudo updates are not caught by the bitbake wrapper.
 This can cause the pseudo-native rebuild in stage2 to cause problems. We can
work around this by:

> rebuild.  We can work around this by:
> 
> * removing the "pseudodone" file in the build directory
> 
> * manually running the "first stage" build:
>   BBFETCH2=True PSEUDO_BUILD=1 ../bitbake/bin/bitbake pseudo-native
> 
> * manually running "bitbake pseudo-native", (still does it as a second stage,
> but usually works)
> 
> Likely what we need to do is figure out a (quick) way in the bitbake wrapper to
> determine if the pseudo has changed... timestamp match to pseudodone?  That of
> course still won't be fool proof.
> 
> What has been discussed in the past is adding the capabilities for a "staged"
> build to bitbake.  Being able to re-invoke the bitbake process after given
> stages [automatically] so that in the end bitbake is in charge of the build
> steps.  So far though not much has been done with this idea, as we're really not
> sure how practical this is.
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core