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 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
