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 > > <[email protected]> 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 > > > > <[email protected]> wrote: > > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote: > > > > > > From: Jacob Kroon <[email protected]> > > > > > > > > > > > > '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 <[email protected]> > > > > > > Signed-off-by: Richard Purdie <[email protected] > > > > > > Signed-off-by: Andreas Müller <[email protected]> > > > > > > > > > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139218): https://lists.openembedded.org/g/openembedded-core/message/139218 Mute This Topic: https://lists.openembedded.org/mt/74669421/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
