Openembedded Core Discussions
 help / color / mirror / Atom feed
* uninative stdc++ abi
@ 2016-03-04 22:33 Richard Purdie
  2016-03-04 23:23 ` Khem Raj
  0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2016-03-04 22:33 UTC (permalink / raw)
  To: Khem Raj; +Cc: openembedded-core

Hi Khem,

I'm trying to get the autobuilders to use uninative and in wider
deployment we're seeing errors like:

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/build
s/700/steps/BuildImages/logs/stdio

 x86_64-linux-libtool: link: gcc -isystem/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -Wl,-rpath-link -Wl,/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath-link -Wl,/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/lib -Wl,-rpath -Wl,/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib -Wl,-rpath -Wl,/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/lib -Wl,-O1 -Bsymbolic-functions -o .libs/test-unicode test_unicode-test-unicode.o  -L/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib -L/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/lib ../../src/.libs/libharfbuzz.so ../../src/.libs/libharfbuzz-icu.so /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/work/x86_64-linux/harfbuzz-native/1.2.3-r0/build/src/.libs/libharfbuzz.so /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib/libglib-2.0.so /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib/libpcre.so -lpthread /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib/libfreetype.so -lz -licuuc -licudata -Wl,-rpath -Wl,/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib
| /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/lib/libicuuc.so: undefined reference to `__cxa_throw_bad_array_new_length@CXXABI_1.3.8'
| collect2: error: ld returned 1 exit status

which I'm guessing is gcc5 verses gcc4 libstdc++ ABI differences? icu
probably built on a gcc 5 machine and is now being used on gcc4 giving
the error?

I'm considering a patch like:


diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 7f242de..5fe0422 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -7,6 +7,12 @@ UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
 #UNINATIVE_CHECKSUM[x86_64] = "dead"
 UNINATIVE_DLDIR ?= "${DL_DIR}"
 
+# https://wiki.debian.org/GCC5
+# We may see binaries built with gcc5 run or linked into gcc4 environment
+# so use the older libstdc++ standard for now until we don't support gcc4
+# on the host system.
+BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"


Is this the right way to try and fix this? Any better ideas?

Cheers,

Richard



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: uninative stdc++ abi
  2016-03-04 22:33 uninative stdc++ abi Richard Purdie
@ 2016-03-04 23:23 ` Khem Raj
  2016-03-04 23:55   ` Andre McCurdy
  0 siblings, 1 reply; 4+ messages in thread
From: Khem Raj @ 2016-03-04 23:23 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

On Sat, Mar 5, 2016 at 6:33 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> +# https://wiki.debian.org/GCC5
> +# We may see binaries built with gcc5 run or linked into gcc4 environment
> +# so use the older libstdc++ standard for now until we don't support gcc4
> +# on the host system.
> +BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
>
>
> Is this the right way to try and fix this? Any better ideas?

yes thats the best option we have given the myriad of build OSes we
have to support.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: uninative stdc++ abi
  2016-03-04 23:23 ` Khem Raj
@ 2016-03-04 23:55   ` Andre McCurdy
  2016-03-05  8:48     ` Richard Purdie
  0 siblings, 1 reply; 4+ messages in thread
From: Andre McCurdy @ 2016-03-04 23:55 UTC (permalink / raw)
  To: Khem Raj; +Cc: openembedded-core

On Fri, Mar 4, 2016 at 3:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Sat, Mar 5, 2016 at 6:33 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>
>> +# https://wiki.debian.org/GCC5
>> +# We may see binaries built with gcc5 run or linked into gcc4 environment
>> +# so use the older libstdc++ standard for now until we don't support gcc4
>> +# on the host system.
>> +BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
>>
>> Is this the right way to try and fix this? Any better ideas?
>
> yes thats the best option we have given the myriad of build OSes we
> have to support.

An alternative would be to configure our uninative gcc5 libstdc++ with:

EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi
--with-default-libstdcxx-abi=gcc4-compatible"

Not sure if that's better though. Just a different approach to achieve
the same thing.

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: uninative stdc++ abi
  2016-03-04 23:55   ` Andre McCurdy
@ 2016-03-05  8:48     ` Richard Purdie
  0 siblings, 0 replies; 4+ messages in thread
From: Richard Purdie @ 2016-03-05  8:48 UTC (permalink / raw)
  To: Andre McCurdy, Khem Raj; +Cc: openembedded-core

On Fri, 2016-03-04 at 15:55 -0800, Andre McCurdy wrote:
> On Fri, Mar 4, 2016 at 3:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> > On Sat, Mar 5, 2016 at 6:33 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > 
> > > +# https://wiki.debian.org/GCC5
> > > +# We may see binaries built with gcc5 run or linked into gcc4
> > > environment
> > > +# so use the older libstdc++ standard for now until we don't
> > > support gcc4
> > > +# on the host system.
> > > +BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
> > > 
> > > Is this the right way to try and fix this? Any better ideas?
> > 
> > yes thats the best option we have given the myriad of build OSes we
> > have to support.
> 
> An alternative would be to configure our uninative gcc5 libstdc++
> with:
> 
> EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi
> --with-default-libstdcxx-abi=gcc4-compatible"
> 
> Not sure if that's better though. Just a different approach to
> achieve
> the same thing.

We don't actually build our own gcc-native with uninative though, we're
trying to keep it small/fast and adding our own gcc doesn't really do
that.

I'm going to test the above and some other fixes on the autobuilder,
see how it looks.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-03-05  8:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-04 22:33 uninative stdc++ abi Richard Purdie
2016-03-04 23:23 ` Khem Raj
2016-03-04 23:55   ` Andre McCurdy
2016-03-05  8:48     ` Richard Purdie

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox