uninative workflow

uninative workflow

[Trevor Woerner]

Hi,

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.

Previously, generating an eSDK didn't require a uninative-tarball, but now,
apparently, it does? Any idea why?

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!

This is getting hard to automate.

In order to create an image and an eSDK I have to start with a local.conf that
doesn't have uninative stuff in it and "bitbake uninative-tarball". Then I can
build my image, then I have to enable the uninative stuff in local.conf,
calculate, and insert the latest md5sum into local.conf, then I can generate
my eSDK. This is getting tricky to automate in, say, a Jenkins job :-(

Am I doing something wrong? It'd be great to go back to the days when the
uninative-tarball wouldn't be required for the eSDK, but maybe that's not
possible?

Best regards,
	Trevor

Re: uninative workflow

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4329 bytes --]

Re: uninative workflow

[Trevor Woerner]

Excellent! Thanks, Ross, for the explanations :-)

On Mon, Nov 21, 2016 at 9:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
>
> 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