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

[Bas Mevissen]

On 2019-05-11 03:42, 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
> 

Apparently [1], there is already a devtoolset-8 [2] with gcc 8.2.
So if going this step, lets directly go to the latest devtoolset version 
available.

The only question is whether only this issue with 1 native package is 
sufficient justification to impose the additional burden to the users. 
If it would make further OE/Yocto core development easier, it would be a 
great way to keep supporting RHEL/CentOS 7 until "8" is mainstream.

(the "scl enable devtoolset-8 <shell>" command could be incorporated 
into the oe-init script to make the burden less)

[1] the collections browser at softwarecollections.org seems to be 
broken or unmaintained, reported this to the appropriate list already
[2] http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-8/

>> Cheers,
>> 
>> Richard
>> 

BR,

Bas.