uninative stdc++ abi
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
@@ -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
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.
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
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 gcc4environment
+# so use the older libstdc++ standard for now until we don't support gcc4meta/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