[OE-core] [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Mon Apr 29 21:22:38 UTC 2019


On Mon, 2019-04-29 at 22:53 +0200, Andreas Müller wrote:
> On Mon, Apr 29, 2019 at 10:26 PM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Mon, 2019-04-29 at 16:07 +0200, Andreas Müller wrote:
> > > This should fix build on ancient hosts
> > > 
> > > Signed-off-by: Andreas Müller <schnitzeltony at gmail.com>
> > 
> > This fixed debian9 but didn't fix centos7 :(
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/150
> > 
> > > checking for a sed that does not truncate output... (cached) sed
> > > checking whether g++  supports C++14 features by default... no
> > > checking whether g++  supports C++14 features with
> > > -std=gnu++14... no
> > > checking whether g++  supports C++14 features with
> > > -std=gnu++1y... no
> > > checking whether g++  supports C++14 features with -std=c++14...
> > > no
> > > checking whether g++  supports C++14 features with +std=c++14...
> > > no
> > > checking whether g++  supports C++14 features with -h
> > > std=c++14... no
> > > checking whether g++  supports C++14 features with -std=c++1y...
> > > no
> > > checking whether g++  supports C++14 features with +std=c++1y...
> > > no
> > > checking whether g++  supports C++14 features with -h
> > > std=c++1y... no
> > > configure: error: *** A compiler with support for C++14 language
> > features is required.
> > 
> I expected that - turns nightmarish..
> 
> > So we may have to look at reverting, or perhaps just adding a vte-
> > native recipe with an older version of vte?
> I have no problem with this but is it a good idea to run self test
> with a different version as the target one?

They're totally different uses so whilst I'd normally be cautious, I'm
not sure it matters so much here.

> What about Ross' suggestion:
> > 3. Don't use vte in qemu when building under virgl.  The gtk
> > PACKAGECONFIG turns on vte support unconditionally but from
> > glancing
> > at the qemu code that isn't a requirement.
> Question: If this is accepted and works properly - could we get rid
> of vte-native then?

I've cc'd Alex, I'm sure there was a good reason we did this. I think
it was to avoid having to have a GL enabled X display so I suspect this
isn't an option.

> Let's decide some option: I really would like to close this and I
> have no problem with either way - gnome-terminal can wait. Gnome
> stuff just hobby to me and for test I can add recent vte in my
> personal meta-verse.

Agreed, we need to make a decision, I'm just making sure we have all
the options and then we "just" need to figure out which one to go for.

vte-native of an older version is looking like the best option unless
Alex says I'm mis-remembering...

Cheers,

Richard



More information about the Openembedded-core mailing list