[yocto] question about SDKMACHINE, SDK_ARCH and BUILD_ARCH

[Richard Purdie]

On Thu, 2011-01-13 at 15:36 -0800, Zhang, Jessica wrote:
> Hi Richard,
>  
> As I mentioned in IRC, we've noticed that bitbake behaves differently
> on 64bit and 32bit machines from SDKMACHINE setup perspective.  It
> never enforces SDKMACHINE to be set in local.conf for 64bit users but
> for 32bit user, if you leave SDKMACHINE unset, the bitbake sanity
> test will fail and prompts user to set the SDKMACHINE to i586.
>  
> It seems internally we really use SDK_ARCH which derived from
> BUILD_ARCH that reflects the poky build machines arch.  And for
> bitbake sanity check if it sees SDK_ARCH is i686, it will prompts user
> to set SDKMACHINE to i586 since there's a known issue for this case
> can't use the default build machine arch of i686.
>  
> Questions are:
> 1. what  is the known issue for using i686?

(e)glibc will fail to build with some issues to do with architecture
optimisations. I don't remember the details but the builds do fail and
the warning is valid. The easy way to test is to disable the warning and
try it!

Once, there were also conflicts between the native bits and the cross
bits both being i686 but I think the problem was solved a long time ago.

At some point it would be nice to fix this but as far as I know the
problem remains and the sanity warning is still valid.

> 2. If we can't resolve the issue for i686, then shouldn't we set the
> SDK_ARCH to i586 as default if the BUILD_ARCH is i686, this way,
> bitbake will behave consistent for 32bit and 64bit if user leave the
> SDKMACHINE unset...

The original code was written simply to stop users building something
that was known not to work. 

I agree the user experience could be better and we could put some inline
python into the default definition of SDKMACHINE to handle this I guess.

Cheers,

Richard