You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The error: libicui18n.so.63: undefined reference to __cxa_throw_bad_array_new_length@CXXABI_1.3.8
My program does not directly depend on ICU.
If I check the sysroot,
...so it seems to be defined. I pass -L /usr/lib/arm-linux-gnueabihf as well. I'd get this error if the archs were different, which is not the case. I fixed the symlinks so it's finding shared libs correctly (I had issues with the linker not finding libpthreads.so and instead linking with libpthreads.a, which caused problems), no that's also not the case.
This seems to be a recurring issue. This is similar to #41#66#75 and to an extent #50 -- what is the root cause?
A solution in one of the issues is to recompile ICU with the toolchain, but my program doesn't even (directly) depend on it and most other dependencies I'm installing via the distro's means (qemu-chroot into the sysroot and use apt to install -dev packages).
Is this a packaging issue from upstream? An incompatibility between the (kinda ol) toolchain and recent libs? Is there another, cleaner, solution that's not recompiling ICU?
My host is an Ubuntu Xenial VM.
My toolchain is arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin from the tools repo - which has no meta-information whatsoever: no readme, install instructions, nothing. The GCC version seems to be 4.8.3 (from arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)).
Use of the toolchains in this repo are deprecated. They are outdated and easily available from other sources (e.g. direct from Ubuntu apt).
e.g. sudo apt-get install gcc-arm-linux-gnueabihf
aarch64 compiler is also available.
The error:
libicui18n.so.63: undefined reference to __cxa_throw_bad_array_new_length@CXXABI_1.3.8
My program does not directly depend on ICU.
If I check the sysroot,
...so it seems to be defined. I pass
-L /usr/lib/arm-linux-gnueabihf
as well. I'd get this error if the archs were different, which is not the case. I fixed the symlinks so it's finding shared libs correctly (I had issues with the linker not findinglibpthreads.so
and instead linking withlibpthreads.a
, which caused problems), no that's also not the case.This seems to be a recurring issue. This is similar to #41 #66 #75 and to an extent #50 -- what is the root cause?
A solution in one of the issues is to recompile ICU with the toolchain, but my program doesn't even (directly) depend on it and most other dependencies I'm installing via the distro's means (qemu-chroot into the sysroot and use
apt
to install-dev
packages).Is this a packaging issue from upstream? An incompatibility between the (kinda ol) toolchain and recent libs? Is there another, cleaner, solution that's not recompiling ICU?
My host is an Ubuntu Xenial VM.
My toolchain is
arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin
from the tools repo - which has no meta-information whatsoever: no readme, install instructions, nothing. The GCC version seems to be 4.8.3 (fromarm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
).My sysroot is 2019-06-20-raspbian-buster.img (first buster, should support all Pis), loopmounted. Last buster gives me similar results.
The text was updated successfully, but these errors were encountered: