Clang build fails under Ubuntu-20.04: undefined reference to `std::__throw_bad_array_new_length()'
junghans opened this issue · comments
When compiling with clang++ on ubuntu:latest (currently 20.04.3 LTS), we get the following :
[ 68%] Linking CXX executable xtp_parallel
/usr/bin/ld: ../libxtp/libvotca_xtp.so.2022: undefined reference to `std::__throw_bad_array_new_length()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [xtp/src/tools/CMakeFiles/xtp_parallel.dir/build.make:97: xtp/src/tools/xtp_parallel] Error 1
make[1]: *** [CMakeFiles/Makefile2:3661: xtp/src/tools/CMakeFiles/xtp_parallel.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
It worked previously, so it might be a problem with using GNU libc with clang-10
It also happens with gcc
The next LTS release will be 22.04, so soon, hence I am not sure we have to fix this issue, which isn't really related to our code anyhow, right now!
@marvinbernhardt @baumeier @JensWehner any opinion on this?
It outside of our control anyhow, no?
https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1956898
If this is indeed the same thing as mentioned in the comments, it seems like it is not a bug.
@jwakely how did you fix said issue on Fedora?
I don't remember seeing this issue on Fedora, sorry. And there is no problem with libstdc++, the problem described on the gcc mailing list was user error, or tool error ... Oleg's libtool was adding -L arguments for gcc-9 libs when compiling with gcc-11. That caused an old libstdc++.so to be found by the linker, which did not provide the necessary symbols that the objects needed (because they'd just been compiled with gcc-11).
The Ubuntu problem is probably the same. Something is being compiled with a new gcc that causes the code to refer to the std::__throw_bad_array_new_length() but then the linker is being told to use libs from an old gcc that missing that symbol.
The commands I gave in https://gcc.gnu.org/pipermail/gcc-help/2021-June/140496.html should help to diagnose if that's the case (or just careful inspection of the -L options passed to the linker).
@jwakely That was very useful! Adding -Wl,--trace-symbol=_ZSt28__throw_bad_array_new_lengthv to the libvotca_xtp.so link lines shows:
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libecpint.a(ecp.cpp.o): reference to _ZSt28__throw_bad_array_new_lengthv
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libecpint.a(ecpint.cpp.o): reference to _ZSt28__throw_bad_array_new_lengthv
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libecpint.a(gaussquad.cpp.o): reference to _ZSt28__throw_bad_array_new_lengthv
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libecpint.a(angular.cpp.o): reference to _ZSt28__throw_bad_array_new_lengthv
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libecpint.a(bessel.cpp.o): reference to _ZSt28__throw_bad_array_new_lengthv
So the problem is actually in the libecpint package, we get from Debian.