Maybe I'm reading RP's reply differently, but I think he just asked to collect all necessary changes for warrior to support newer host, before they are accepted.
It doesn't help much when only one smaller issue is fixed and the rest still needs to be figured out locally and the commit message might even mislead people in assuming that gcc-10 on host is now supported in warrior/thud. FWIW: I've built some smaller thud based images on 20.04 with only small modifications, e.g. fix for qemu: https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/thud&id=68475d0255c4089538886d1ee2cab6b6efd62ce1 there aren't probably many issues left, so it just needs someone to test it more properly and collect all needed fixes to apply them at the same time or give up if it shows too many difficult to solve issues (I doubt that). In worst case they might be rejected, but then it would be still useful to have them in one pull request and share them with other interested parties. Cheers, On Thu, Jun 4, 2020 at 3:58 PM Quentin Schulz < [email protected]> 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? > > Cheers, > Quentin > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139219): https://lists.openembedded.org/g/openembedded-core/message/139219 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]] -=-=-=-=-=-=-=-=-=-=-=-
