Bug 3667

I am reassigning it to oe-core as it doesn't seem related to the BSP but a generic issue.

In fact the build here works fine and I cannot reproduce it in any way maybe someone have a light on it.

Regards,

I did several builds without reproducing this one; closing as worksforme.

This bug has been reproduced on the autobuilder:

http://autobuilder.yoctoproject.org:8010/builders/nightly-fsl-arm/builds/29/steps/shell_71/logs/stdio


Cheers,
Constantin

I have faced it several times, but with a bitbake avahi -c cleansstate everything worked

It seems the issue got fixed in Poky as last builds has been completed fine.

Closing it.

It still fails:

http://autobuilder.yoctoproject.org:8010/builders/nightly-fsl-arm/builds/35/steps/shell_71/logs/stdio

Cheers,
Constantin

I had a look at this and its some kind of cross contamination between the imx53qsb build and the imx6qsabresd one. The way to reproduce is probably to build avahi with imx53qsb and save off the sstate, remove avahi itself, remove the imx53qsb build directory (or move it) then try a clean imx6qsabresd build of avahi using the sstate.

I've found the problem. The imx53qsb and imx6qsabresd machines share a package architecture (armv7a) so they should only be built once for that package archicture. Unforunately they have different linux-libc-header versions. This means they each get a different eglibc and each get a different set of packages.

This should just result in a rebuild but there are libtool contamination problems in the source trees which is a known issue (need to separate ${S} and ${B} which is a different and big problem).

Do these freescale board really need different headers? Can we please use the same default as the core yocto project, then armv7a only need build *once*, not once per set of libc-headers.

(In reply to comment #8)
> I've found the problem. The imx53qsb and imx6qsabresd machines share a
> package architecture (armv7a) so they should only be built once for that
> package archicture. Unforunately they have different linux-libc-header
> versions. This means they each get a different eglibc and each get a
> different set of packages.
> 
> This should just result in a rebuild but there are libtool contamination
> problems in the source trees which is a known issue (need to separate ${S}
> and ${B} which is a different and big problem).
> 
> Do these freescale board really need different headers? Can we please use
> the same default as the core yocto project, then armv7a only need build
> *once*, not once per set of libc-headers.

As discussed on IRC I believe we can move to Yocto's headers and avoid this rebuild; It will save build time for all us.

I'll send patches for it.

(In reply to comment #9)
> (In reply to comment #8)
> > I've found the problem. The imx53qsb and imx6qsabresd machines share a
> > package architecture (armv7a) so they should only be built once for that
> > package archicture. Unforunately they have different linux-libc-header
> > versions. This means they each get a different eglibc and each get a
> > different set of packages.
> > 
> > This should just result in a rebuild but there are libtool contamination
> > problems in the source trees which is a known issue (need to separate ${S}
> > and ${B} which is a different and big problem).
> > 
> > Do these freescale board really need different headers? Can we please use
> > the same default as the core yocto project, then armv7a only need build
> > *once*, not once per set of libc-headers.
> 
> As discussed on IRC I believe we can move to Yocto's headers and avoid this
> rebuild; It will save build time for all us.
> 
> I'll send patches for it.

I've give it a shot and it is not easy to remove the kernel headers.

The GPU stack depends on framebuffer and other SOC features and those are provided by linux-headers.

So this is a blocker for the removal of the headers for now.

I'd suggest those things should be depending on the actual kernel itself, not the libc headers which are used by libc. That would make the graphics stack machine dependent but I think that is more reasonable than the whole system.

The way you have it setup now, you may as well mark all packages as machine specific.

Yes; I agree this should be the way to go but it is not a simple thing to change by myself ... so I need help from Freescale people to look for alternatives; do you have any idea how this might be done?

*** Bug 3861 has been marked as a duplicate of this bug. ***

This issue is still happening on autobuilder:
http://autobuilder.yoctoproject.org:8010/builders/nightly-fsl-arm/builds/67/steps/shell_71/logs/stdio

This has been fixed with the work to use Yocto's libc headers instead of FSL specific ones.

This issue is still happening on autobuilder:

http://autobuilder.yoctoproject.org:8010/builders/nightly-fsl-arm/builds/116/steps/shell_71/logs/stdio

It seems the rebuild is due the libgcc being rebuild if we change tune features, as:

~/hacking/fsl-community-bsp/build% bitbake-diffsigs tmp/stamps/armv7a-vfp-neon-poky-linux-gnueabi/libgcc/4.7.2-r18.do_multilib_install.sigdata.*
basehash changed from 4bf0524702b24aaca817c22072a15462 to a79803c847cff7af072d44ece1553a2b
Variable AVAILTUNES value changed from ' armv4 armv4t armv4b armv4tb armv5 armv5t armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp armv5b armv5tb armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp armv5eb armv5teb armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp armv6-novfp armv6t-novfp armv6 armv6t armv6hf armv6thf armv6b-novfp armv6tb-novfp armv6b armv6tb armv6hfb armv6thfb armv7a armv7at armv7a-neon armv7at-neon armv7ahf armv7athf armv7ahf-neon armv7athf-neon armv7ab armv7atb armv7ab-neon armv7atb-neon armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon cortexa8 cortexa8t cortexa8-neon cortexa8t-neon cortexa8hf cortexa8thf cortexa8hf-neon cortexa8thf-neon' to ' armv4 armv4t armv4b armv4tb armv5 armv5t armv5-vfp armv5t-vfp armv5hf-vfp armv5thf-vfp armv5b armv5tb armv5b-vfp armv5tb-vfp armv5hfb-vfp armv5thfb-vfp armv5e armv5te armv5e-vfp armv5te-vfp armv5ehf-vfp armv5tehf-vfp armv5eb armv5teb armv5eb-vfp armv5teb-vfp armv5ehfb-vfp armv5tehfb-vfp armv6-novfp armv6t-novfp armv6 armv6t armv6hf armv6thf armv6b-novfp armv6tb-novfp armv6b armv6tb armv6hfb armv6thfb armv7a armv7at armv7a-neon armv7at-neon armv7ahf armv7athf armv7ahf-neon armv7athf-neon armv7ab armv7atb armv7ab-neon armv7atb-neon armv7ahfb armv7athfb armv7ahfb-neon armv7athfb-neon cortexa9 cortexa9t cortexa9-neon cortexa9t-neon cortexa9hf cortexa9thf cortexa9hf-neon cortexa9thf-neon'

Anyone spot what we're doing wrong?

For one you have cortexa8, the other cortexa9 which is resulting in the difference. We may need to whitelist AVAILTUNES...

Cheers,

Richard

This seems to be need for libgcc recipe; checking the signature for it, it changes for multilib_install task however I didn't find a way to whitelist it.

Can someone provide some input on this?

I'd guess something like http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=64ff7eaa33b5fa229bf23dd2c8816420732d321b should work.

(In reply to comment #20)
> I'd guess something like
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/
> t2&id=64ff7eaa33b5fa229bf23dd2c8816420732d321b should work.

It does fix it; can you please commit this one?

Fixed in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9bfd92243eced921f166d84b5a72d6f774e13413