Ubuntu 20.04 doesn't have gcc 10 as default, it's still 9. So I guess that's different from Fedora 32 that someone mentioned.
Regards //Ernst Thu 2020-06-04 klockan 15:06 +0100 skrev Richard Purdie: 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 < <mailto:[email protected]> [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 < <mailto:[email protected]> [email protected] > wrote: On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote: From: Jacob Kroon < <mailto:[email protected]> [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 < <mailto:[email protected]> [email protected] > Signed-off-by: Richard Purdie < <mailto:[email protected]> [email protected] Signed-off-by: Andreas Müller < <mailto:[email protected]> [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 (#139220): https://lists.openembedded.org/g/openembedded-core/message/139220 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]] -=-=-=-=-=-=-=-=-=-=-=-
