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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
