GCC ARM交叉编译，未定义的对__cxa_end_catch@CXXABI_1.3的引用之类的错误指示什么? [英] GCC ARM Cross-Compiling, what do errors like undefined reference to `__cxa_end_catch@CXXABI_1.3' indicate?
问题描述
我使用用于FPGA SoC的英特尔嵌入式开发套件成功地为Intel Cyclone V SoC构建了测试应用程序.此应用程序链接到某些目标系统特定的库.
I successfully built a test application for an Intel Cyclone V SoC with the Intel Embedded Development Suite for FPGA SoCs. This application links against some target system specific libraries.
由于EDS随附的GCC已经过时，并且我需要较新的C ++功能，因此我想用最新版本的arm-linux-gnueabihf-g ++进行编译，下载了
As the GCC shipped with the EDS is quite outdated and I need newer C++ features, I wanted to compile the whole thing with a current version of arm-linux-gnueabihf-g++ which I downloaded here from the ARM website.
使用最新的GCC编译使用原始工具链构建良好的同一项目会导致很多错误，如下所示:
Compiling the same project that builds fine with the original toolchain with the recent GCC leads to lots of errors like this:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `__cxa_end_catch@CXXABI_1.3'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::string const&, std::_Ios_Openmode)@GLIBCXX_3.4'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `std::cerr@GLIBCXX_3.4'
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/ld: intelFPGARootDir/18.1/hld/host/arm32/lib/libalteracl.so: undefined reference to `operator delete(void*)@GLIBCXX_3.4'
libalteracl.so 是Intel发行的特定于目标系统的库之一.显然这里不匹配，但是我不确定确切的问题是什么.因此，我需要对如何解释此错误以及如何解决这些错误进行一些解释.
libalteracl.so is one of the target system specific libraries distributed by Intel. Obviously something doesn't match here, however I'm not sure what's the exact problem. So, I need some explanation of how to interpret this errors and what could be done to fix them.
评论中出现了一些问题，下面是一些其他信息
目标体系结构是双核ARM Cortex A9.我在上面链接的ARM网站上加载了 AArch32目标下列出的ARM并带有硬浮点(arm-linux-gnueabihf).
Target Architecture is a Dual-Core ARM Cortex A9. I loaded the ARM listed under AArch32 target with hard float (arm-linux-gnueabihf) on the ARM website linked above.
构建由CMake/CLion完成.提取的生成的Compiler/Linker调用如下:
The build is done by CMake / CLion. The extracted generated Compiler/Linker calls are as follows:
编译:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -DCL_HPP_MINIMUM_OPENCL_VERSION=110 -DCL_HPP_TARGET_OPENCL_VERSION=200 -DJUCE_APP_CONFIG_HEADER=\"myProjectDir/JuceLibraryCode/AppConfig.h\" -DOPEN_CL_INTEL_FPGA -D_DEBUG=1 -IsomeFrameworkDir/JUCE/modules -IintelFPGARootDir/18.1/hld/host/include20 -g -std=gnu++11 -o CMakeFiles/HostApplication.dir/Source/Main.cpp.o -c myProjectDir/Source/Main.cpp
链接:
pathToNewGcc-ARM/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -g -LintelFPGARootDir/18.1/hld/board/de10_standard/arm32/lib -LintelFPGARootDir/18.1/hld/host/arm32/lib -LintelFPGARootDir/18.1/hld/host/arm32/lib -Wl,--no-as-needed -lalteracl -lintel_soc32_mmd -lstdc++ -lelf CMakeFiles/HostApplication.dir/Source/Main.cpp.o CMakeFiles/HostApplication.dir/JuceLibraryCode/include_juce_core.cpp.o -o HostApplication -lrt -ldl -lpthread
libalteracl.so 应该是32位的库，因为整个目标体系结构都是32位的
libalteracl.so should be a 32 Bit library as the whole target Architecture is 32 Bit
推荐答案
看来，这是因为您的工具链中的libstdc ++没有提供版本化的符号...
It seems, the reason for this is that libstdc++ in your toolchain does not provide versioned symbols...
在主机上，我得到
$ readelf -sW /usr/lib64/libstdc++.so.6 | c++filt | grep std::cerr | grep @
3091: 000000000018d340 272 OBJECT GLOBAL DEFAULT 25 std::cerr@@GLIBCXX_3.4
$ readelf -sW /usr/lib64/libstdc++.so.6 | grep __cxa_end_catch | grep @
1997: 000000000008fe60 131 FUNC GLOBAL DEFAULT 11 __cxa_end_catch@@CXXABI_1.3
但是我看不到您提供的链接的工具链的版本符号:
But I don't see the versioned symbols for the toolchain you provided a link to:
$ readelf -sW ./arm-linux-gnueabihf/libc/usr/lib/libstdc++.so.6.0.25 | c++filt | grep std::cerr | grep @
(nothing)
所以我认为 libalteracl.so 已与提供符号版本的libstdc ++链接.也许您会更幸运地使用同一供应商提供的早期工具链.
So I think libalteracl.so has been linked against libstdc++ that provided versioned versions of the symbols. Maybe you'll have more luck with earlier toolchains from the same vendor.
从该手册中:
先决条件
支持版本化ABI的最小环境:受支持的动态链接器，足够老的GNU链接器可以理解脱钩的C ++名称遍历(ld)或Sun链接器，使用g ++编译的共享可执行文件和共享库(libgcc_s，libstdc ++)由具有兼容ABI的编译器(g ++)编译.ew.
Minimum environment that supports a versioned ABI: A supported dynamic linker, a GNU linker of sufficient vintage to understand demangled C++ name globbing (ld) or the Sun linker, a shared executable compiled with g++, and shared libraries (libgcc_s, libstdc++) compiled by a compiler (g++) with a compatible ABI. Phew.
最重要的是，还有一个附加的约束:libstdc ++直到版本3.1.0才尝试对符号进行版本化(或确实适当地老化).
On top of all that, an additional constraint: libstdc++ did not attempt to version symbols (or age gracefully, really) until version 3.1.0.
大多数现代GNU/Linux和BSD版本(尤其是使用GCC 3.1和更高版本的版本)将满足上述要求，Solaris 2.5及更高版本也将满足以上要求.
Most modern GNU/Linux and BSD versions, particularly ones using GCC 3.1 and later, will meet the requirements above, as does Solaris 2.5 and up.
配置
事实证明，大多数更改默认行为的配置选项都会影响导出符号的名称混乱，从而影响版本控制和兼容性.
It turns out that most of the configure options that change default behavior will impact the mangled names of exported symbols, and thus impact versioning and compatibility.
有关配置选项(包括ABI影响)的更多信息，请参见:此处
For more information on configure options, including ABI impacts, see: here
有一个标志专门用于处理符号版本控制:-enable-symvers .
There is one flag that explicitly deals with symbol versioning: --enable-symvers.
这篇关于GCC ARM交叉编译，未定义的对__cxa_end_catch@CXXABI_1.3的引用之类的错误指示什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
