交叉编译静态库的链接顺序

交叉编译时遇到：undefined reference to `XXX'.

解决办法：

一，用nm看看库里边是不是有对应的符号：

nm *.a/*.lib/*.so |grep "XXX"

二，看看是不是被strip过了：

$ file libusb-1.0.a libusb-1.0.so.0.1.0
libusb-1.0.a: current ar archive
libusb-1.0.so.0.1.0: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped

三，添加-v参数看看有没有别的线索

四，查看链接的库是不是添加了软连接到别的库了，而那个库版本不对应！

五，将XXX.o这种一般写在最前面，而后面的sdk提供的lib和a（被依赖者），使劲儿往后写。

参考相关资料：

-Wl选项告诉编译器将后面的参数传递给链接器。

《c专家编程》第五章。

《Linkers and Loaders》。

在链接静态库时，如果多个静态库之间存在依赖关系，则有依赖关系的静态库之间存在链接顺序问题。这在使用静态库时需要注意，否则会报符号找不到的链接错误。
例如：
lib2.a 依赖于 lib1.a，而最终可执行文件 test 依赖于 lib2.a，则链接选项应为：-llib2.a -llib1.a，而不能反过来，否则会报 lib1.a 中的某些符号未定义。

当程序员们使用多个库的时候，如果库之间存在循环依赖的时候经常需要将库列出多次。就是说，如果一个库A中的例程依赖一个库B中的例程，但是另一个库B中的例程又依赖了库A中的另一个例程，那么从A扫描到B或从B扫描到A都无法找到所有需要的例程。当这种循环依赖发生在三个或更多的库之间时情况会更加糟糕。告诉链接器去搜索A B A或者B A B，甚至有时为A B C D A B C D，这种方法看上去很丑陋，但是确实可以解决这个问题。将多个.o文件链接成可执行文件的时候。如果链接的顺序不对，会产生错误。

《An introduction of gcc》里面有下面一段话：
On Unix-like systems, the traditional behavior of compilers and linkers
is to search for external functions from left to right in the object files
specified on the command line. This means that the object file which
contains the definition of a function should appear after any files which
call that function.
但是也说了：
Most current compilers and linkers will search all object files, regardless
of order, but since not all compilers do this it is best to follow the
convention of ordering object files from left to right.
链接库的时候，也存在这个问题。
今天写程序做了一下试验，发现gcc和我现在用的一个板子的编译器都可以不用严格按照顺序。
但是同时发现了另一个问题，就是我们自己的操作系统提供的库文件有两个：libgcc.a和libcs.a。
链接的时候要加上 -lcs -lgcc ，如果这两个顺序搞乱了，就会报错。