On 18 November 2016 at 21:30, Trevor Woerner <twoerner@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@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