[OE-core] [PATCH 1/1] pseudo: Fix problem related to realpath
Mark Hatle
mark.hatle at windriver.com
Fri Jun 10 15:19:50 UTC 2011
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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
More information about the Openembedded-core
mailing list