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

[Bas Mevissen]

On 2019-05-13 13:34, Mark Hatle wrote:
> 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).
> 

If I recall correctly, CentOS properly only supports up to C++-11.

> 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.)
> 

Agreed. But that was attempted already and seemed to fail.

> 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.
> 

Or simply build a gcc{,-c++}-native on platforms where the existing host 
compiler is too old?

It might even be a way to be able to build _older_ OE/Yocto on newer 
distros. For example, I now use a CentOS 7 systemd container to build 
Morty stuff on my Fedora 30 build host as some older stuff does not 
build on the newer build environment of Fedora since some time.

> 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.
> 

Yes, RHEL/CentOS 7 has been great, but RHEL/CentOS 8 to me feel like a 
year late. I hope with "8" we can leverage the modular repository 
function to keep the devtools updated.

Given the wide spread in host environments (origin and age), one could 
wonder whether more of the host build environment should be simply part 
of OE/Yocto build system as native packages. This will make development 
definitely easier. The only expense is a larger host environment for the 
user.

-- bas.

> --Mark
> 
>>> Cheers,
>>> 
>>> Richard
>>>