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 <ab...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
