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

[Mark Hatle]

On 5/11/19 4:42 AM, Khem Raj wrote:
> 
> 
> On 4/29/19 6:51 AM, richard.purdie at linuxfoundation.org wrote:
>> On Mon, 2019-04-29 at 15:47 +0200, Andreas Müller wrote:
>>> On Mon, Apr 29, 2019 at 2:21 PM Andreas Müller <
>>> schnitzeltony at gmail.com> wrote:
>>>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse at basmevissen.nl
>>>>> wrote:
>>>>> On 2019-04-29 11:29, Andreas Müller wrote:
>>>>>
>>>>> (...)
>>>>>
>>>>>> Understood - hope to find time till tomorrow for this. Need to
>>>>>> find an
>>>>>> old machine for test because otherwise further fixes might
>>>>>> remain
>>>>>> incomplete again.
>>>>>>
>>>>>
>>>>> Why not add the g++ option --std=c++11 when test building this
>>>>> recipe?
>>>>>
>>>>> $cat test.cc
>>>>>
>>>>> #include <string>
>>>>>
>>>>> using namespace std::literals;
>>>>>
>>>>> int main()
>>>>> {
>>>>>          return 0;
>>>>> }
>>>>>
>>>>>
>>>>> $ g++ --std=c++17 test.cc -o test
>>>>> $ g++ --std=c++11 test.cc -o test
>>>>> test.cc:5:22: error: ‘literals’ is not a namespace-name
>>>>>       5 | using namespace std::literals;
>>>>>         |                      ^~~~~~~~
>>>>>
>>>>> -- Bas.
>>>> Did that but on CFLAGS (copy & paste from another place in recipe)
>>>> and
>>>> since issues popped up I thought it was right :(
>>>>
>>> Looked into:
>>>
>>> There is no easy way to get vte-native to build with c++11. Even if -
>>> patches possibly introduce functional changes/errors (and the result
>>> of oe-selftest is questionable with a massively patched vte).
>>>
>>> So I see two ways to go:
>>>
>>> 1. set vte-native requirements to c++14. That worked here with
>>> CXXFLAGS_append_class-native = " --std=c++14" but looking into logs
>>> of
>>> centos 7 there are several '--std=gnu++11'. Have no idea where they
>>> come from so chances are high this patch is going fail with c++14.
>>> 2. revert vte back to 0.52.2 and forget the idea to get recent
>>> gnome-terminal back in near future. That requires vte 0.56.1 and was
>>> the reason I sent the update here.
>>>
>>> My preference is 2.
>>
>> I'm willing to try testing a c++14 patch if that helps, we can fall
>> back to 2 if that fails?
>>
> 
> Can we require centos7 and other hosts which use old compilers to 
> install the additional packages to have newer compilers ? e.g. for 
> centos installing devtoolset-7 will fix this issue

I think we need to consider disabling this by default, as Ross indicated he
wasn't sure it was really required, as well as consider the c++14 patch (if
standard CentOS supports C++-14).

I do think it's reasonable to try to patch this component, assuming it can be
done in a reasonable way with a reasonable end result.  (10-lines is pretty easy
to understand/support, 1000 lines... no so much.)

However, once we get past one component into multiples, then we need a better
answer.  Either a set of buildtools the user can build/download, or items
standard distributions have that they can install.

Unfortunately CentOS 7 (and corresponding RHEL) is ancient by compiler
standards, but is heavily used as a replacement is not yet ready.  So this is a
problem we'll need to deal with for a while still.  Until CentOS 7 era is really
no longer heavily used I think we don't have a choice here but to deal with this
one way or another.

--Mark

>> Cheers,
>>
>> Richard
>>