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

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

[Andreas Müller]

This should fix build on ancient hosts

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 ...uce-gcc-required-support-downto-c-11.patch | 34 ++++++++++++++
 ...001-Revert-parser-glue-Use-std-clamp.patch | 44 +++++++++++++++++++
 ...replace-std-clamp-by-std-min-std-max.patch | 33 ++++++++++++++
 meta/recipes-support/vte/vte_0.56.1.bb        |  7 +++
 4 files changed, 118 insertions(+)
 create mode 100644 meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-11.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch

diff --git a/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-11.patch b/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-11.patch
new file mode 100644
index 0000000000..9c839d6d26
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-11.patch
@@ -0,0 +1,34 @@
+From 6d33f959f442f1338846f6f80e826f1345951b57 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 12:52:03 +0200
+Subject: [PATCH] Reduce gcc required support downto c++11
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Native builds require host gcc and they might not support full c++17 but enough
+to build vte-native.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1c7a753b..698e795d 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -97,7 +97,7 @@ AC_HEADER_STDC
+ AM_PROG_CC_C_O
+ AC_PROG_SED
+ 
+-AX_CXX_COMPILE_STDCXX([17])
++AX_CXX_COMPILE_STDCXX([11])
+ 
+ AC_SYS_LARGEFILE
+ 
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch b/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
new file mode 100644
index 0000000000..581996d3c4
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
@@ -0,0 +1,44 @@
+From 9e562ebaf4c01f864cd5791ad759465cb32a9dc5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 13:03:33 +0200
+Subject: [PATCH] Revert "parser: glue: Use std::clamp"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+std::clamp requires c++17
+
+Upstream-Status: Inappropriate [configuration]
+
+This reverts commit 1a84c427cd2ea05939b86eb47c21a437d0ce6d79.
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ src/parser-glue.hh | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/parser-glue.hh b/src/parser-glue.hh
+index c12bb784..9c23a0a3 100644
+--- a/src/parser-glue.hh
++++ b/src/parser-glue.hh
+@@ -281,7 +281,7 @@ public:
+                                    int max_v) const noexcept
+         {
+                 auto v = param(idx, default_v);
+-                return std::clamp(v, min_v, max_v);
++                return std::min(std::max(v, min_v), max_v);
+         }
+ 
+         /* param_nonfinal:
+@@ -381,7 +381,7 @@ public:
+                                       int max_v) const noexcept
+         {
+                 int v = __builtin_expect(idx < size(), 1) ? vte_seq_arg_value_final(m_seq->args[idx], default_v) : default_v;
+-                return std::clamp(v, min_v, max_v);
++                return std::min(std::max(v, min_v), max_v);
+         }
+ 
+         /* collect_subparams:
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch b/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch
new file mode 100644
index 0000000000..ef53458858
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch
@@ -0,0 +1,33 @@
+From db3b9cceb55130b0a4b3414be804530c368ececc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 13:22:52 +0200
+Subject: [PATCH] vte.cc: replace std:clamp by std:min(std:max(..)..)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+std::clamp requires c++17
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ src/vte.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/vte.cc b/src/vte.cc
+index 0aa9a3fc..c9faab49 100644
+--- a/src/vte.cc
++++ b/src/vte.cc
+@@ -5125,7 +5125,7 @@ Terminal::resolve_selection_endpoint(vte::grid::halfcoords const& rowcolhalf, bo
+                 /* Just find the nearest cell boundary within the line, not caring about CJKs, unused
+                  * cells, or wrapping at EOL. The @after parameter is unused in this mode. */
+                 col += half;
+-                col = std::clamp (col, 0L, m_column_count);
++                col = std::min (std::max(col, 0L), m_column_count);
+         } else {
+                 switch (m_selection_type) {
+                 case selection_type_char:
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte_0.56.1.bb b/meta/recipes-support/vte/vte_0.56.1.bb
index 3585e9ce57..bc49809521 100644
--- a/meta/recipes-support/vte/vte_0.56.1.bb
+++ b/meta/recipes-support/vte/vte_0.56.1.bb
@@ -19,6 +19,13 @@ SRC_URI += "file://0001-Don-t-enable-stack-protection-by-default.patch \
            file://0001-app.cc-use-old-school-asignment-to-avoid-gcc-4.8-err.patch \
            file://0001-Add-W_EXITCODE-macro-for-non-glibc-systems.patch \
            "
+
+SRC_URI_append_class-native = " \
+    file://0001-Reduce-gcc-required-support-downto-c-11.patch \
+    file://0001-Revert-parser-glue-Use-std-clamp.patch \
+    file://0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch \
+"
+
 SRC_URI[archive.md5sum] = "a8984cd5a101dbff0b0c875d1de3f692"
 SRC_URI[archive.sha256sum] = "02fa8ecc02a9332e47f486795494527b5687b3bd448e73e6b67285f2f326dc7c"
 
-- 
2.20.1

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

[Richard Purdie]

On Sat, 2019-04-27 at 13:37 +0200, Andreas Müller wrote:
> This should fix build on ancient hosts
> 
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> ---
>  ...uce-gcc-required-support-downto-c-11.patch | 34 ++++++++++++++
>  ...001-Revert-parser-glue-Use-std-clamp.patch | 44
> +++++++++++++++++++
>  ...replace-std-clamp-by-std-min-std-max.patch | 33 ++++++++++++++
>  meta/recipes-support/vte/vte_0.56.1.bb        |  7 +++
>  4 files changed, 118 insertions(+)
>  create mode 100644 meta/recipes-support/vte/vte/0001-Reduce-gcc-
> required-support-downto-c-11.patch
>  create mode 100644 meta/recipes-support/vte/vte/0001-Revert-parser-
> glue-Use-std-clamp.patch
>  create mode 100644 meta/recipes-support/vte/vte/0001-vte.cc-replace-
> std-clamp-by-std-min-std-max.patch

Unfortunately it doesn't seem to be quite enough:

https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/461993/raw
(from centos 7)

| ../../vte-0.56.1/src/utf8-test.cc:27:22: error: ‘literals’ is not a
namespace-name
|  using namespace std::literals;
|                       ^

and:

https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/461960/raw
(from debian9)

| ../../vte-0.56.1/src/parser-cat.cc:140:31: error: enclosing class of
constexpr non-static member function ‘bool PrettyPrinter::plain()
const’ is not a literal type
|          inline constexpr bool plain() const noexcept { return
m_plain; }
|                                ^~~~~
| ../../vte-0.56.1/src/parser-cat.cc:134:7: note: ‘PrettyPrinter’ is
not literal because:
|  class PrettyPrinter {
|        ^~~~~~~~~~~~~

Unfortunately I merged the upgrade into master as we'd had green builds
before this (chance meant we didn't hit this failure) so this is a more
pressing problem now...

Cheers,

Richard

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

[Andreas Müller]

On Mon, Apr 29, 2019 at 10:49 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Sat, 2019-04-27 at 13:37 +0200, Andreas Müller wrote:
> > This should fix build on ancient hosts
> >
> > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > ---
> >  ...uce-gcc-required-support-downto-c-11.patch | 34 ++++++++++++++
> >  ...001-Revert-parser-glue-Use-std-clamp.patch | 44
> > +++++++++++++++++++
> >  ...replace-std-clamp-by-std-min-std-max.patch | 33 ++++++++++++++
> >  meta/recipes-support/vte/vte_0.56.1.bb        |  7 +++
> >  4 files changed, 118 insertions(+)
> >  create mode 100644 meta/recipes-support/vte/vte/0001-Reduce-gcc-
> > required-support-downto-c-11.patch
> >  create mode 100644 meta/recipes-support/vte/vte/0001-Revert-parser-
> > glue-Use-std-clamp.patch
> >  create mode 100644 meta/recipes-support/vte/vte/0001-vte.cc-replace-
> > std-clamp-by-std-min-std-max.patch
>
> Unfortunately it doesn't seem to be quite enough:
>
> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/461993/raw
> (from centos 7)
>
> | ../../vte-0.56.1/src/utf8-test.cc:27:22: error: ‘literals’ is not a
> namespace-name
> |  using namespace std::literals;
> |                       ^
>
> and:
>
> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/461960/raw
> (from debian9)
>
> | ../../vte-0.56.1/src/parser-cat.cc:140:31: error: enclosing class of
> constexpr non-static member function ‘bool PrettyPrinter::plain()
> const’ is not a literal type
> |          inline constexpr bool plain() const noexcept { return
> m_plain; }
> |                                ^~~~~
> | ../../vte-0.56.1/src/parser-cat.cc:134:7: note: ‘PrettyPrinter’ is
> not literal because:
> |  class PrettyPrinter {
> |        ^~~~~~~~~~~~~
>
> Unfortunately I merged the upgrade into master as we'd had green builds
> before this (chance meant we didn't hit this failure) so this is a more
> pressing problem now...
>
> Cheers,
>
> Richard
>
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.

Andreas

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

[Bas Mevissen]

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.

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

[Andreas Müller]

On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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 :(

Andreas

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

[Andreas Müller]

On Mon, Apr 29, 2019 at 2:21 PM Andreas Müller <schnitzeltony@gmail.com> wrote:
>
> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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.

Cheers

Andreas

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

[Burton, Ross]

On Mon, 29 Apr 2019 at 14:48, Andreas Müller <schnitzeltony@gmail.com> wrote:
> 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.

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.

Ross

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

[richard.purdie]

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@gmail.com> wrote:
> > On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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?

Cheers,

Richard

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

[Bas Mevissen]

On 2019-04-29 15:47, Andreas Müller wrote:
> On Mon, Apr 29, 2019 at 2:21 PM Andreas Müller 
> <schnitzeltony@gmail.com> wrote:
>> 
>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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.

In Centos 7, its gcc-c++ is 4.8.5 currently. That version does not fully 
support 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.
> 

vte 0.56.2 and 0.57 are out already. So better focus on one of those 
versions instead of 0.56.1.

> My preference is 2.
> 
> Cheers
> 
> Andreas

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

[Khem Raj]

On 4/29/19 6:51 AM, richard.purdie@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@gmail.com> wrote:
>>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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

> Cheers,
> 
> Richard
> 

Re: [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@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@gmail.com> wrote:
>>>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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.

Re: [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@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@gmail.com> wrote:
>>>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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
>>

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

[richard.purdie]

On Mon, 2019-05-13 at 14:34 +0300, Mark Hatle wrote:
> On 5/11/19 4:42 AM, Khem Raj wrote:
> > 
> > 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.

We avoided the problem by dropping the dependency so we're ok again for
now. We haven't required special things be installed on hosts as it
increases the documentation problem quite a lot. We run our autobuilder
test workers fairly standard for this reason.

The problem is going to get worse over time and the other solution
could be we require one of our own buildtools-tarballs installed too.
We have used this approach on our autobuilder workers in the past.

I am keen to avoid extra distro specific documentaiton (and patches to
detect the conditions) if we can help it...

Cheers,

Richard

Re: [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@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@gmail.com> wrote:
>>>>> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen <abuse@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
>>> 

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On Mon, May 13, 2019 at 4:40 AM <richard.purdie@linuxfoundation.org> wrote:

> On Mon, 2019-05-13 at 14:34 +0300, Mark Hatle wrote:
> > On 5/11/19 4:42 AM, Khem Raj wrote:
> > >
> > > 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.
>
> We avoided the problem by dropping the dependency so we're ok again for
> now. We haven't required special things be installed on hosts as it
> increases the documentation problem quite a lot. We run our autobuilder
> test workers fairly standard for this reason.
>
> The problem is going to get worse over time and the other solution
> could be we require one of our own buildtools-tarballs installed too.
> We have used this approach on our autobuilder workers in the past.
>
> I am keen to avoid extra distro specific documentaiton (and patches to
> detect the conditions) if we can help it...
>

It’s a balance to strike in my opinion sometimes we go out of way to keep
supporting ancient compilers that has its own disadvantages At the same
time if we ask for additional packages for certain hosts this could also
mean that if they were building older releases those may not build anymore
with new compiler so it’s a dicey situation

>
> Cheers,
>
> Richard
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3161 bytes --]