移植内容是将修改版的ORB-SLAM2工程移植到ARM+DSP（FPGA实现）系统上。
项目来源于导师（苦逼的打工人/(ㄒoㄒ)/~~），由于该项目涉及到公司商业信息，我只是讲述有关移植部分的通用经历。
一、环境搭建与安装
因为我之前已经在笔记本上安装了Ubuntu20.04，所以一上来，我就不管三七二十一，直接在网上搜索ORB-SLAM2的安装与运行教程，找到一个后，跟着步骤来。
在安装opencv的时候，一开始选择的是3.4.12，结果中途报错（错误及解决方法见：https://stackoverflow.com/questions/46884682/error-in-building-opencv-with-ffmpeg），个人猜测与opencv版本与gcc版本有关（后面会提到）。
解决opencv的安装后，我直接就在发来的原工程里运行./build.sh，编译过程中也遇到了一个问题：
1 | /usr/include/c++/9/bits/stl_map.h:122:71: error: static assertion failed: std::map must have the same value_type as its allocator |
经过查询，需要改一下源码中一个头文件的typedef内容（https://blog.csdn.net/lixujie666/article/details/90023059），同样，这个问题显然也与gcc版本有关（因为他们发给我的东西肯定都是测试能跑通的，可惜当时我没有意识到gcc版本的问题）。
编译好后，想都没想，直接运行Examples中的Monocular例子，报找不到动态链接库xxx的问题，于是经过搜索，了解到了ld.so.conf、ld.so.conf.d、ldconfig和ldd这些东西，是用于管理Linux下的动态链接库的。参考链接如下：
但是修改过后，反复尝试编译了很多遍，Monocular中的例子仍然报错。。。许久之后，绝望之中决定查看CMakeLists.txt的内容，看看是否没有添加相关的库。结果一看就发现了问题所在——原来是因为这个CMakeLists.txt被他们的工程师给修改过了，只产生RGB-D中的可执行文件。。。
于是得到第一条经验：在接收别人修改过的工程后，最好先看看CMakeLists.txt中的内容。
于是运行RGB-D中的例子，仍然报错，并且是找不到DBoW2和g2o两个动态链接库，我寻思这不是自带的吗？build.sh中也有相关的编译过程。于是再次编译整个过程，仔细查看发现问题：新建build文件夹失败，文件夹已存在，balabala……
原来是原来编译的东西没有删除。。。
于是得到第二条经验：重新编译工程的时候最好把原来编译的残留文件都删除。
删除之后再次重新编译运行，这次终于成功运行了程序，激动不已，但是几秒后，程序就结束了运行——opencv报错。经过各种搜索，都没有找到ORB-SLAM2遇到过这种问题的。于是想是不是opencv版本的问题？经过询问，他们使用的是opencv3.4.9，于是重新安装 ，但是结果还是一样/(ㄒoㄒ)/~~
怀着近乎崩溃的心情，把这个错误截下来，发给了他们的工程师，得到的一个重要信息是，他们使用的 ubuntu版本是16.04，同时gcc版本与我的不同，他们建议我安装16.04版本。
但是作为经历过许多次重装系统的我，不想再经历一次了（重装系统本身不麻烦，麻烦的是重装后的软件安装、环境配置）。。。
于是把希望放在gcc的版本上，查询到16.04的默认gcc大版本为5，而20.04的是9.3版本，差距有点大(lll￢ω￢)。。。直接apt get install gcc-5是不成功的，因为20版本的软件源里没有版本5（最低的貌似是7），于是查询ubuntu gcc降级及多版本共存的方法（https://blog.csdn.net/EternallyAccompany/article/details/108865331），原理就是添加16.04的源（所以可以换成16.04的国内源），然后更新、安装 。
安装后得到5.3.1的gcc和g++，重新编译、运行工程，功夫不负有心人，最终成功运行！！！
于是得到第三条经验：对于C++项目来说，GCC、G++的版本很重要！因为C++的复杂机制与杂乱的标准，导致不同版本的编译器编译同一个项目时，结果可能会不一样（比如一个 通过，另一个报错），这也是C++广遭吐槽的一点。
同时，总结出第四条经验：要积极主动地与他人沟通，接收项目时一定要事先询问好搭建的环境（系统、编译器版本和环境），不要害羞。
未完待续…..