* 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