由于我们的板子是arm架构，而开发使用的pc机器是x86架构，所以在pc机上开发出来的程序要想在arm板子上运行，需要用交叉编译工具链，类似arm-linux-gcc这种，编译成arm平台上可运行的二进制文件才可以。如果你除了自己写的代码，还引用了一些第三方库，类似boost这种，你还得把boost库也用交叉编译工具重新编译下才能用。当然还要注意32位64位这种问题。

我一开始只把g++换成了arm-linux-g++，编译后运行，结果报错说找不到动态库。所以我决定进行静态编译，将需要的库都编译进可执行文件中，在目标平台上可直接运行。

于是我就在makefile文件的后面加了一个 -static，来进行静态编译。编译成功了，但是有一个tcp的某个函数里有一个关于glibc的警告，如下： 但我没管他，想着如果tcp出现问题再去看这个警告。 于是我再运行的时候果然就可以成功运行了。正当我开心的时候，问题出现了： 板子上运行的程序好好的，在用boost库解析xml的时候突然发生了段错误。我顺着发生段错误的地方，一行一行调试，最终锁定了在了一个boost库new出来的局部变量上。 现象是，只要这个变量被释放，程序就会段错误。 这真是奇了怪了。大家知道局部变量都是存在栈区的，而且离开作用域即会释放内存。一个局部变量招谁惹谁了，居然一释放就段错误？

我怀疑是系统的问题，平台的问题，板卡的问题。于是我更换了另一个arm平台的板卡，发现一模一样的段错误也发生了。其他的关于程序上的怀疑也不对，因为该程序在x86平台上运行的好好的，所以程序出bug的可能性也很小。

十分不合常理的问题。虽然出错的是boost 的局部变量，但是这种诡异或不合常理的事情一发生，那你就不能从眼前那个问题去找答案了，它可能是别的问题，引发了眼前的这个极其不合常理的问题。至此，我开始回头看那个警告。

它貌似是在说，gethostbyname在动态库中,却用static的方式链接了。因此我把boost的库用静态链接，把pthread这种标准库用了动态链接，写法是这样：

编译后果然没有警告了。 我放到板子上运行以后，发现报错找不到c++标准库，即libstdc++.so.6.这个板子上啥都没有，c++的标准库还是装一个比较好，要不然连helloworld都运行不了。所以我拷贝了一个32位的libstdc++.so.6的动态库到板子上，再执行就全部ok啦。