Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Thu, 2020-06-04 at 15:57 +0200, Quentin Schulz wrote:
> On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > > 
> > > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > > > 
> > > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > > default.
> > > > > > 
> > > > > > (Backport of OE-Core rev:
> > > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > > > 
> > > > > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > > > > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > > > > 
> > > > > Does warrior otherwise work on gcc10 hosts?
> > > > Not yet but I am working on it.
> > > 
> > > I think to make a decision on whether we plan to support gcc10 or not
> > > we'll need to know the scope of the changes. I'm starting to worry this
> > > would be a bit too invasive, particularly as warrior is about to enter
> > > community support or EOL depending on whether there is a maintainer.
> > > 
> > I see. Problems for me - job's hat on - are:
> > 
> > 1. we're close to release a product based on warrior (and a new
> > colleague of mine has just installed Fedora 32 with gcc 10 - that's
> > why I ask for it)
> > 2. my tests with dunfell were - hmm - not running out of the box exactly.
> > 
> > So we should decide to upgrade to dunfell. That is what I use for
> > private raspi-images an am very close to happy.
> > 
> 
> Dang, I was silently but closely following the discussion hoping to be
> able to apply more or less the same patches on top of thud. Same issue
> as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
> docker time :/ (there'll always be that one client that will not want to
> upgrade to newer releases).
> 
> Or maybe we can support gcc10 on the community branch once it's EOL (or
> doing the job ourselves..). What seems to be the big worry about
> supporting gcc10 on warrior/thud? Just so I can explain why we should go
> the docker route instead of spending time on making thud (and we still
> have krogoth for some...) build with gcc10 and maybe start working on
> upgrading those we can to newer releases. Basically what are the
> expected big hurdles on the way?

Your other option would be buildtools tarball for the f32/ubuntu2004
systems.

I could see a case for backporting the buildtools tarball
installer/wrapper for those older releases as a way of fixing these
issues.

Cheers,

Richard