Skip to contentSkip to conversation

uninative stdc++ abi

PATCH Richard Purdie 3 participants 4 messages Mar 4, 2016 – Mar 5, 2016

lore
Share & tools
lore
#0 lore raw

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:

meta/classes/uninative.bbclass +5 -0
index 7f242de..5fe0422 100644
@@ -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

#1 lore raw
Quoted 9 lines · Richard Purdie
meta/classes/uninative.bbclass +5 -0
+# 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.

#2 lore raw
Quoted 9 lines · Khem Raj
Quoted 7 lines · Richard Purdie
meta/classes/uninative.bbclass +5 -0
+# 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"
Quoted 4 lines
Quoted 1 line

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.

Quoted 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#3 lore raw
Quoted 20 lines · Andre McCurdy
Quoted 11 lines · Khem Raj
Quoted 9 lines · Richard Purdie
(quoted diff) +2 -0
+# 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

meta/classes/uninative.bbclass +2 -0
+# on the host system.
+BUILD_CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
Quoted 4 lines
Quoted 1 line

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:

Quoted 6 lines

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