[OE-core] Building older releases on modern distros (and vice versa)

Khem Raj raj.khem at gmail.com
Fri Jan 17 18:58:07 UTC 2020


On 1/17/20 10:57 AM, Richard Purdie wrote:
> On Fri, 2020-01-17 at 10:39 -0800, Khem Raj wrote:
>> On 1/17/20 9:59 AM, Richard Purdie wrote:
>>> We've been discussing how we could:
>>>
>>> a) build old releases on newer distros
>>>
>>> as well as
>>>
>>> b) how we could build new releases on old distros.
>>>
>>> Our proposed answer has been "buildtools-extended-tarball" which
>>> includes nativesdk-gcc.
>>>
>>> We need b) so we can install this on Centos7 and stop having to
>>> work
>>> around its really old compiler. In general this should improve our
>>> ability to support stable branches in general.
>>>
>>> I wanted to stress test a) a bit, partly to prove that b) could
>>> work
>>> longer term.
>>>
>>> I did this by attempting to build buildtools-extended-tarball on
>>> pyro
>>> which has a gcc v6 and then using that to build morty on an Ubuntu
>>> 18.04 system.
>>>
>>> It wasn't plain sailing, I had to:
>>>
>>> * Upgrade the uninative in pyro
>>> * Switch to xz uninative to allow latest uninative to work
>>> * Patch binutils to fix an ld.so.conf relocation issue
>>> * Add an ld.so.conf to buildtools
>>> * Add the buildtools-extended-tarall recipe
>>>
>>> Patches are in:
>>>
>>> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/pyro
>>>
>>> (some need forward porting to master)
>>>
>>> Having got the output from the pyro build, in the morty build I
>>> added
>>> buildtools tarball to PATH before running the build. I had to
>>> disable
>>> uninative since it was going to get in the way and conflict:
>>>
>>
>> do we intend to generate extended buildtools tarballs for all
>> releases
>> if it works out well ?
> 
> Going forward there will be one generated as part of the release
> process for each release, they're part of master builds already.
> 
> We only really need a couple of older older ones with older gccs to be
> able to support a range of different older releases but we should look
> to generate those.
> 

Perhaps it will be good to have one with gcc 4.8 ( pre c++11 days )

> Cheers,
> 
> Richard
> 



More information about the Openembedded-core mailing list