* Pyro's uninative and libstdc++ symbols
@ 2017-08-25 12:50 Raphael Kubo da Costa
2017-08-25 14:55 ` Chris Z.
2017-08-29 8:03 ` Richard Purdie
0 siblings, 2 replies; 6+ messages in thread
From: Raphael Kubo da Costa @ 2017-08-25 12:50 UTC (permalink / raw)
To: yocto
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pyro's uninative and libstdc++ symbols
2017-08-25 12:50 Pyro's uninative and libstdc++ symbols Raphael Kubo da Costa
@ 2017-08-25 14:55 ` Chris Z.
2017-08-29 8:03 ` Richard Purdie
1 sibling, 0 replies; 6+ messages in thread
From: Chris Z. @ 2017-08-25 14:55 UTC (permalink / raw)
To: Raphael Kubo da Costa; +Cc: yoctoproject
Hi,
You could try to build your own uninative:
bitbake uninative-tarball
and use your own uninative:
update: poky/meta/conf/distro/include/yocto-uninative.inc
Or stop using uninative.
But I'm also curios why native built with newer gcc is not using glibc
from uninative (older glibc than gcc 7 uses)
Br,
Chris Z
On Fri, Aug 25, 2017 at 2:50 PM, Raphael Kubo da Costa
<raphael.kubo.da.costa@intel.com> 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?
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pyro's uninative and libstdc++ symbols
2017-08-25 12:50 Pyro's uninative and libstdc++ symbols Raphael Kubo da Costa
2017-08-25 14:55 ` Chris Z.
@ 2017-08-29 8:03 ` Richard Purdie
2017-09-01 19:14 ` akuster
1 sibling, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2017-08-29 8:03 UTC (permalink / raw)
To: Raphael Kubo da Costa, yocto
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
version in master. uninative works on the principle that it the same
version or newer than the host system and for older releases this
ceases to be the case unless we upgrade it.
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pyro's uninative and libstdc++ symbols
2017-08-29 8:03 ` Richard Purdie
@ 2017-09-01 19:14 ` akuster
2017-09-01 21:44 ` Richard Purdie
0 siblings, 1 reply; 6+ messages in thread
From: akuster @ 2017-09-01 19:14 UTC (permalink / raw)
To: Richard Purdie, Raphael Kubo da Costa, yocto
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?
-= Armin
> version in master. uninative works on the principle that it the same
> version or newer than the host system and for older releases this
> ceases to be the case unless we upgrade it.
>
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pyro's uninative and libstdc++ symbols
2017-09-01 19:14 ` akuster
@ 2017-09-01 21:44 ` Richard Purdie
2017-09-07 14:28 ` Raphael Kubo da Costa
0 siblings, 1 reply; 6+ messages in thread
From: Richard Purdie @ 2017-09-01 21:44 UTC (permalink / raw)
To: akuster, Raphael Kubo da Costa, yocto
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...
Cheers,
Richard
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Pyro's uninative and libstdc++ symbols
2017-09-01 21:44 ` Richard Purdie
@ 2017-09-07 14:28 ` Raphael Kubo da Costa
0 siblings, 0 replies; 6+ messages in thread
From: Raphael Kubo da Costa @ 2017-09-07 14:28 UTC (permalink / raw)
To: Richard Purdie; +Cc: yocto
Richard Purdie <richard.purdie@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!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-07 14:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-25 12:50 Pyro's uninative and libstdc++ symbols Raphael Kubo da Costa
2017-08-25 14:55 ` Chris Z.
2017-08-29 8:03 ` Richard Purdie
2017-09-01 19:14 ` akuster
2017-09-01 21:44 ` Richard Purdie
2017-09-07 14:28 ` Raphael Kubo da Costa
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.