我用英特尔嵌入式开发套件（Intel Embedded Development Suite for FPGA SoCs）成功地为英特尔Cyclone V SoC构建了一个测试应用程序。此应用程序链接到某些特定于目标系统的库。
由于用EDS装运的GCC已经过时了，我需要更新的C++特性，所以我想用ARM LIUX-GNUEABIHF+G+的当前版本编译整个项目，我从ARM网站下载了here。
使用最新的GCC编译使用原始工具链构建良好的同一项目会导致许多错误，如：
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是英特尔发布的目标系统特定库之一。很明显这里有些东西不匹配，但是我不确定到底是什么问题。所以，我需要一些解释，如何解释这些错误，以及如何解决它们。由于评论中出现了一些问题，下面是一些附加信息
目标架构是一个双核臂皮层A9。我在上面链接的ARM网站上加载了AArch32 target下列出的ARM和hard float（ARM linux gnueabihf）。
构建由CMake/CLion完成。提取的生成编译器/链接器调用如下：
编译：
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位的 最佳答案
这似乎是因为工具链中的libstdc++没有提供版本化的符号。。。
在我的主机上，我得到
$ 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
但我看不到你提供的工具链的版本符号链接到：
$ readelf -sW ./arm-linux-gnueabihf/libc/usr/lib/libstdc++.so.6.0.25 | c++filt | grep std::cerr | grep @
(nothing)
所以我认为
libalteracl.so与libstdc++相关联，libstdc++提供了符号的版本。也许你会有更多的运气与早期的工具链从同一个供应商。从the manual：
先决条件
支持版本化ABI的最小环境：一个支持的动态链接器，一个GNU链接器，具有足够的年份，以理解解散的C++名称GLUBIN（LD）或Sun链接器，用G++编译的共享可执行文件，以及由兼容的ABI编译的编译器（G++）编译的共享库（LIGBGCYS，LIbSTDC++）。啊。
除此之外，还有一个额外的限制：libstdc++直到3.1.0版才尝试对符号进行版本化（或者说是优雅地老化）。
大多数现代GNU/Linux和BSD版本，特别是使用GCC 3.1及更高版本的版本，都将满足上述要求，Solaris 2.5及更高版本也是如此。
配置
事实证明，大多数更改默认行为的配置选项都会影响导出符号的损坏名称，从而影响版本控制和兼容性。
有关配置选项（包括ABI影响）的更多信息，请参见：此处
有一个标志显式地处理符号版本控制：
--enable-symvers。