前段时间在把某个x86架构系统上运行的程序迁移到arm架构系统时，发现了一些比较有意思的编译问题，跟大家分享一下迁移方法和遇到的一些坑。

背景：

在x86架构linux系统上能够成功编译和运行的程序，需要迁移到arm架构的linux系统中。

迁移注意事项：原有功能不能有影响，尽量少修改代码和makefile，迁移后的程序要能够兼容x86架构和arm架构。

迁移方法：

1.兼容arm和x86的编译脚本判断语句编写方法

CMakelist

IF(${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64")
	SET(CMAKE_CXX_FLAGS "-fPIC -DLINUX -m64 -Wall -Wno-unused-function -Wno-unused-parameter -std=c++11 ")
ELSEIF(CMAKE_HOST_SYSTEM_PROCESSOR MATCHS "aarch64")
	SET(CMAKE_CXX_FLAGS "-fPIC -DLINUX -march=armv8-a -mabi=lp64 -mtune=tsv110 -fsigned-char -Wall -Wno-unused-function -Wno-unused-parameter -std=c++11 ")
ELSE() 
	SET(CMAKE_CXX_FLAGS "-fPIC -DLINUX -Wall -Wno-unused-function -Wno-unused-parameter -std=c++11 ")
ENDIF()

Makefile

ifeq ($(shell arc), "x86_64")
	CPPFLAGS=-g -O2 -m64
else ifeq ($(shell arc), "aarch64")
   CPPFLAGS=-g -O2 -march=armv8-a -mabi=lp64 -mtune=tsv110 -fsigned-char 
else 
	CPPFLAGS=-g -O2 -m64
endif

shell

get_arch=`arch` 
if [[ $get_arch =~ "x86_64" ]];then
	echo "this is x86_64" 
elif [[ $get_arch =~ "aarch64" ]];then
	echo "this is arm64" 
else 
	echo "unknown!!"
fi

2.arm架构的主要编译选项

(1)x86_64的-m64编译选项在arm架构不兼容，需要换成-mabi=lp64

(2)char变量在不同cpu架构下默认符号不一致，在x86架构下为signed char，在arm架构下为unsigned char，所以需要添加编译选项-fsigned-char

(3)添加编译选项-ffp-contract=off，可以优化浮点运算精度

(4)添加编译选项-march=armv8-a和-mutune=tsv110，可以提升性能

迁移过程中发现的疑难问题：

下面列举几个我遇到的比较难搞的问题，跟大家分享一下我在遇到这些问题时的环境、解决思路，以及我的建议。

问题：

程序link时，提示：undefined reference to `std__cxx11:basic_stringstream<char, std:char_traits<char>, std:allocator<char> >:basic_stringstream()@GLIBCXX_3.4.26'

思路：

(1)先提取此编译问题的关键词：undefined reference to、cxx11:basic_stringstream、GLIBCXX_3.4.26

(2)然后分别分析或上网查看这些关键词出现的可能原因和对策。

(3)对这些原因的可能对策进行初步分析后开始挨个尝试

实际操作：

网上有很多这些关键词相关的文章，此处我就不一一详细列举了，下面说一下我的操作方向。

(1)依赖库问题

虽然这个程序使用了动态库，但是那个动态库是能够正确编译的，且在x86架构下编译、链接、运行也都是好用的，所以应该不是makefile或cmakelist中动态库链接方法的问题。

但是考虑到不同cpu架构下链接的顺序有可能调整，尝试修改cmakelist中动态库链接顺序后问题仍然存在，所以判断问题并不是出在依赖库上。

(2)c++11编译器兼容问题

依据：

如出现std::__cxx11命名空间或abi:cxx11中未定义符号的链接错误，很可能是因为链接了使用不同的_GLIBCXX_USE_CXX11_ABI宏编译的目标，在链接旧版gcc编译的第三方库中经常出现。如第三方库无法使用新的ABI编译，则需使用旧版ABI重新编译本地代码。

尝试方法：

添加_GLIBCXX_USE_CXX11_ABI宏的使用，在cmakelist 中添加 :add_definitions(-D_GLIBCXX_USE_CXX11_ABI=0)，但是依然报错，将宏改为1也依然报错。所以初步判断问题并不是出在c++11编译器兼容问题上。

备注：_GLIBCXX_USE_CXX11_ABI宏使用说明，

-D_GLIBCXX_USE_CXX11_ABI=0 // 链接到旧版本，未启用c++11特性，std::string是std::basic_string<char>，如将c++11下的string当作参数传入非c++11库，就会出现error: cannot convert 'const std::__cxx11::basic_string<char>' to 'const char*'，或者未定义的方法引用（undefined reference）

-D_GLIBCXX_USE_CXX11_ABI=1 // 链接到新版本

(3)编译器兼容问题

根据错误提示前面列出的编译器路径，找到编译器的库，然后通过strings查看编译器版本信息，发现是兼容GLIBCXX_3.4.26的，所以不是编译器兼容问题。

那这个问题到底是什么原因导致的呢？正在百思不得其解时，突然意识到查看的这个libstdc++.so是根据编译错误提示上路径找到的，那我自己主动搜一下，是否存在其他的地方也有libstdc++.so的库，但是又不兼容GLIBCXX_3.4.26，恰好此程序要引用的动态库被这个libstdc++.so编译的呢？

此时，使用find命令查找了一下，果然发现了多个路径下存在libstdc++.so[恐惧]

我在程序的Cmakelist中强制添加了gcc和g++库的路径，发现程序可以编译链接通过了，那么，恭喜自己，终于找到问题所在了。

分析：

Q1:为什么会存在这么多次的编译器安装呢？

A1:因为项目内暂时就个别几台环境供我们使用，且这个机器最开始并没有安装编译器，是后来使用的同事自己安装的，但是不同项目的同事使用时分别安装了自己使用过的版本，所以导致编译器版本和安装路径比较多

建议：一个环境中只使用一套编译器，如果需要安装不同版本编译器的话，建议重新申请一台服务器，或使用其他用户权限进行操作。

Q2:编译时都使用默认编译器应该是可以的，为什么还会出现问题呢？

A1:因为这个程序的Cmakelist中没有设置gcc和g++的编译选项，所以程序编译和链接时就不知道会出现什么未知问题了。

建议：养成良好的编码习惯，在Cmakelist中，添加默认编译选项，比如

SET(CMAKE_CXX_COMPILER "g++")
SET(CMAKE_C_COMPILER "gcc")

对于迁移中的其他问题，等以后有时间会继续更新到本文章中，大家可以先关注收藏。