Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On Mon, May 13, 2019 at 4:40 AM 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 > > > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
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.pur...@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 <
schnitzelt...@gmail.com> wrote:
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen
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
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On 5/11/19 4:42 AM, Khem Raj wrote:
>
>
> On 4/29/19 6:51 AM, richard.pur...@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 <
>>> schnitzelt...@gmail.com> wrote:
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen 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
>
> 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
>>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On 2019-05-11 03:42, Khem Raj wrote:
On 4/29/19 6:51 AM, richard.pur...@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 <
schnitzelt...@gmail.com> wrote:
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen
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
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 " 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.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On 4/29/19 6:51 AM, richard.pur...@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 <
schnitzelt...@gmail.com> wrote:
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen
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
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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On 2019-04-29 15:47, Andreas Müller wrote:
On Mon, Apr 29, 2019 at 2:21 PM Andreas Müller
wrote:
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen
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
>
> 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
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 <
> schnitzelt...@gmail.com> wrote:
> > On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen > > 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
> > >
> > > 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On Mon, 29 Apr 2019 at 14:48, Andreas Müller 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On Mon, Apr 29, 2019 at 2:21 PM Andreas Müller wrote:
>
> On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen 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
> >
> > 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On Mon, Apr 29, 2019 at 12:56 PM Bas Mevissen 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
>
> 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
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
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.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
On Mon, Apr 29, 2019 at 10:49 AM Richard Purdie
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
> > ---
> > ...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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] vte-native: reduce c++ requirements from c++17 -> c++11
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
> ---
> ...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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
