[OE-core] [PATCH 1/1] pseudo: Fix problem related to realpath

[Mark Hatle]

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
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.