[yocto] uninative workflow
twoerner at gmail.com
Mon Nov 21 08:06:16 PST 2016
Excellent! Thanks, Ross, for the explanations :-)
On Mon, Nov 21, 2016 at 9:40 AM, Burton, Ross <ross.burton at intel.com> wrote:
> On 18 November 2016 at 21:30, Trevor Woerner <twoerner at gmail.com> wrote:
>> To be honest, I'm not entirely sure what the uninative stuff is
>> or pointers to explanations appreciated!) but I'm trying to figure out how
>> work with it.
> It's a prebuild glibc designed to remove the differences between host
> distros, meaning that native sstate objects can be shared between host
> distros. It used to be opt-in for convenience but there's a nasty build
>> Previously, generating an eSDK didn't require a uninative-tarball, but
>> apparently, it does? Any idea why?
> classes/populate_sdk_ext: require uninative
> It seems that possibly due to OE-Core commit
> ac59063bee0e32d0737340974f657341717a6abe, binaries produced without
> uninative aren't compatible with the uninative glibc. I did try earlier
> to ensure that the eSDK could work without uninative since the default
> configuration in OE-Core does not enable it, but it seems like I didn't
> go far enough. Given the practical considerations, just give up and
> require uninative to be enabled in order to build the eSDK. I'm not
> particularly happy about this, but I don't seem much of an alternative.
> Fixes [YOCTO #10566].
> uninative: Add a fix for icu-native to use the correct ABI
> If no -std= option is passed to icu's configure, it defaults to CXX11.
> This isn't what we want for uninative, so pass an explicit option
> which selects an older ABI on newer versions of g++.
> This avoids the __cxa_bad_array_new_length at CXXABI_1.3.8 symbol
> being used.
>> So now, in addition to building the uninative-tarball before being able to
>> build an eSDK, it also appears that I have to edit my local.conf to tell
>> build that I'm using it, where to find it, and its md5sum. The weird thing
>> I could do "bitbake uninative-tarball" all day long, and every invocation
>> that command will generate a tarball with a different md5sum even though
>> configuration for each build is exactly the same!
> You're Doing It Wrong. Generate the uninative tarball once, put it
> somewhere central, update configuration file.
> Or, just do what poky does:
> require conf/distro/include/yocto-uninative.inc
> INHERIT += "uninative"
> That uses the uninative tarball that is hosted on the yoctoproject site, so
> you only need to build your own if you don't want to trust external
More information about the yocto