[yocto] Pyro's uninative and libstdc++ symbols

[Raphael Kubo da Costa]

Richard Purdie <richard.purdie at linuxfoundation.org> writes:

> On Fri, 2017-09-01 at 12:14 -0700, akuster wrote:
>> On 08/29/2017 01:03 AM, Richard Purdie wrote:
>> >
>> > On Fri, 2017-08-25 at 14:50 +0200, Raphael Kubo da Costa wrote:
>> > >
>> > > I've recently updated my host system to Fedora 26, which has GCC
>> > > 7.
>> > >
>> > > This seems to be causing some issues on Pyro, where I have a
>> > > -native
>> > > recipe that is built with my system's g++ and ends up generating
>> > > a
>> > > binary with the following symbol:
>> > >
>> > >      0000000000000000      DF
>> > > *UND*  0000000000000000  GLIBCXX_3.4.23
>> > > std::basic_string<char, std::char_traits<char>,
>> > > std::allocator<char>
>> > > >
>> > > > ::basic_string(std::string const&, unsigned long,
>> > > std::allocator<char> const&)
>> > >
>> > > GLIBCXX_3.4.23 is not part of Pyro's uninative's libstdc++, so
>> > > when
>> > > that
>> > > binary is invoked in another (non-native) recipe as part of
>> > > do_configure
>> > > it fails to run:
>> > >
>> > >      gn: /data/src/yocto/poky/build/tmp/sysroots-
>> > > uninative/x86_64-
>> > > linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.23' not found
>> > > (required by gn)
>> > >
>> > > Is there anything I should be doing differently here?
>> > We need to update the uninative version in pyro to the more recent
>> is this action just a straight forward backport from Master?
>
> Yes, should be...

For the record, I think Richard fixed this with pyro commit
98dcaa9d2c95328eedd6d3608f41c808509348b4 ("uninative: Update to 1.7
uninative release"). I can confirm I can continue using all the
uninative bits on Fedora 26 now. Thanks!