因为命令行确实没有指出符号所在的库文件，所以报错。找到相应库文件，先添加到命令行中吧。

    方法1是最直接简单的方式，在命令行的结尾再给ld一次找该符号的机会。理论上，因为已经知道符号就在该库中定义，所以ld就能从新添加的这个选项中找到该标号。此法对于简单的小规模程序很合适。

    不过对于Makefile管理的大项目就不行了。因为通常大项目会定义“LIBS”之类的变量。若LIBS变量插在链接命令行的中间位置，且 Makefile 中链接命令过多，在逐个命令最后添加新选项可是个易出错、难维护的体力活。

    这是最文雅的方式。用“ -start-group“ 和”-end-group”扩起来的 .a文件会被反复解析，直到所有的符号都找到定义。因为这些选项都是给链接器ld用的,所以加上了”-Wl,”,代表紧接的选项传给链接器。默认情况下，ld会自动加上“-start-group -lgcc -lgcc_eh -lc -end-group”.意思是找不到的符号／函数名就在这几个库里面使劲搜，因为这几个库太底层了，符号间有依赖。

    虽然这种方式能避免方法1中易出错、难维护的体力活。不过因为需要反复的解析其中的库文件，如果.a文件过多过大的时候，会增加链接时间。

    这是最KISS的方法，简单高效。既然多个.a文件间存在循环引用依赖，ld解决不了循环依赖关系。那么我们可以参考从集群、网格计算到云计算的进化过程。把一坨.a揉成一个.a文件(ar命令可以实现此操作)，交给ld。这样循环依赖问题就解决了。

    这种方式避免了ld反复解析同一个.a文件，降低链接时间开销。不过该方法比较适合项目开发时使用，因为需要调整Makefile，而且将哪些.a揉成一个.a也是一个问题。比如我遇到的错就是因为pthread库函数出现undefined reference，标准库很多的时候也有点头大。