[yocto] uninative workflow

[Trevor Woerner]

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
>> (explanations
>> or pointers to explanations appreciated!) but I'm trying to figure out how
>> to
>> 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
> failure.
>
>>
>> Previously, generating an eSDK didn't require a uninative-tarball, but
>> now,
>> apparently, it does? Any idea why?
>
>
> b59eee7bebd413c7abe5626f69508e1fe47dd0ac:
>     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].
>
> ac59063bee0e32d0737340974f657341717a6abe:
>     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
>> the
>> build that I'm using it, where to find it, and its md5sum. The weird thing
>> is,
>> I could do "bitbake uninative-tarball" all day long, and every invocation
>> of
>> that command will generate a tarball with a different md5sum even though
>> the
>> 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
> binaries.
>
> Ross