>>> I run massive parallel builds with 8 bitbake threads and make -j 8, so
>>> I suspect that this has something to do with it. One of the tasks the
>>> is started before is linux-libc-headers_2.6.31.bb, do_package_stage.
>>> Could it be that this task hasn't finished yet while the
>>> gcc-cross-initial needs it?
>>>
>>> Regards,
>>>
>>> Jan
>>>
>>
>> It seems to pick up a header file from the host.
>> It could also be dependent of glibc-initial or so.
>> What happens if you build from scratch with 1 thread and -j 1 ?
>
> Then it works. I'll try checking the dependencies for glibc-initial.
OK, i think there is something strange going on here.
In gcc-cross-initial.inc: PROVIDES = "virtual/${TARGET_PREFIX}gcc-initial"
In glibc.inc: PROVIDES = "virtual/${TARGET_PREFIX}libc-for-gcc"
In glibc-initial.inc: DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial"
In gcc-cross.inc: DEPENDS = "virtual/${TARGET_PREFIX}libc-for-gcc"
I'd say that there is a circular dependency here.
Could this explain why the problem occurs in a multi-threaded build
environment and not in a single threaded one?
What's the way to solve this? Is there some way in bitbake to synchronize this?
Jan
>
> Jan
>>
>> Frans
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
