> Op 18 nov. 2016, om 19:06 heeft Richard Purdie > <[email protected]> het volgende geschreven: > > On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote: >> On 11/17/2016 09:31 AM, Burton, Ross wrote: >>> Background: uninative is a class that downloads a precompiled host >>> glibc for use in the sysroot, thus isolating the native sysroot >>> from the host environment. This means greater sstate reuse, as >>> instead of native builds being dependent on the host system they're >>> able to be shared between all hosts. There is a reference tarball >>> hosted on www.yoctoproject.org, and the URL can be overridden by >>> distros if you would prefer to build your own. >>> >>> We enable this in Poky so that we get greater reuse on the >>> autobuilders, and due to some issues with the C++ ABI the eSDK >>> generation in master now requires uninative to be enabled. The >>> question is: do we now enable uninative by default in oe-core's >>> nodistro (pointing at the yoctoproject tarball), or do we keep it >>> disabled by default and require the user to enable uninative if >>> they wish to build an eSDK? >> >> If Poky wants the default to use a prebuilt uninative that is fine, >> but it should be not be the default in OE. In the spirit of Bitbake, >> uninative should be a build dependency for eSDK with the option of >> using a prebuilt one. > > Its not that simple. Using uninative requires certain options passed in > when compiling native recipes for example, e.g. to pick particular C++ > abis. If you start the build without those set (since uninative is > disabled), you can't get native sstate built in the right way for it to > work with eSDK. We could of course add a new BBCLASSEXTEND, "native2" > which is native specially for use in the eSDK but that seems silly. > > I guess we could move the configuration uninative requires into global > bitbake.conf but not require the actual binary shim to be enabled. That > would let eSDK work in OE-Core just not make OE-Core require uninative. > It would mean the compiler options for native would be a little > different. That might be an acceptable compromise?
It would be for me. regards, Koen -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
