uninative limitation: UNINATIVE_MAXGLIBCVERSION

uninative limitation: UNINATIVE_MAXGLIBCVERSION

[Alan Kozlay]

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

All,

Why does uninative.bbclass (around line 86) revert to my hosts glibc if
that version is above the uninative version but our sstate-cache is only
local (not hosted/shared)?

I want to know in general terms (what could go wrong), but in case you're
wondering, my specific environment is:

Building with "zeus" release but can't update, at this time.  The "zeus"
release provides glibc *2.31* uninative glibc.

My build machine is running Fedora 33 (glibc *2.32*) and I'm leveraging
the x86_64-buildtools-extended-nativesdk-standalone-3.1 tool.  Yes, I know
that "zeus" is 3.0 but the "extended" version (also provides a compatible
native gcc) wasn't introduced until the 3.1 version of the standalone
tools.  But 3.1 seems to work after back porting some 3.1 fixes into some
bbappend files I made.

But, again, my question is about the general case and not specifically my
environment.

Anyone?
-Alan

-- 
NOTICE: This communication (including any attachments) may contain 
information that is proprietary, confidential or exempt from disclosure. If 
you are not the intended recipient, please note that further dissemination, 
distribution, use or copying of this communication is strictly prohibited. 
Anyone who received this message in error should notify the sender 
immediately by telephone or by return email and delete it from his or her 
computer.

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

Re: [OE-core] uninative limitation: UNINATIVE_MAXGLIBCVERSION

[Richard Purdie]

On Tue, 2021-01-19 at 12:15 -0500, Alan Kozlay wrote:
> All,
> Why does uninative.bbclass (around line 86) revert to my hosts glibc
> if that version is above the uninative version but our sstate-cache
> is only local (not hosted/shared)?
> 
> I want to know in general terms (what could go wrong), but in case
> you're wondering, my specific environment is:
> 
> Building with "zeus" release but can't update, at this time.  The
> "zeus" release provides glibc 2.31 uninative glibc.
> 
> My build machine is running Fedora 33 (glibc 2.32) and I'm leveraging
> the x86_64-buildtools-extended-nativesdk-standalone-3.1 tool.  Yes, I
> know that "zeus" is 3.0 but the "extended" version (also provides a
> compatible native gcc) wasn't introduced until the 3.1 version of the
> standalone tools.  But 3.1 seems to work after back porting some 3.1
> fixes into some bbappend files I made.
> 
> But, again, my question is about the general case and not
> specifically my environment.
> 
> Anyone?

Your build will generate binaries that link to glibc 2.32 specific
symbols. These can then be added to sstate and since uninative only has
2.31, they won't work on a system that doesn't have glibc 2.32. This
means that it would break the promises about being able to share sstate
between distros.

glibc is only backwards compatible, not forwards compatible so there
isn't anything we can do to fix this limitation, only detect and avoid
problems by separating the binaries.

I'd note that upgrading just uninative to a new version should be a
safe operation and should be able to be cherry-picked alone safely.

Cheers,

Richard