编译源代码时报错:
/opt/toolchains/uclibc-crosstools-gcc-4.2.3-3/usr/bin/../lib/gcc/mips-linux-uclibc/4.2.3/../../../../mips-linux-uclibc/bin/ld: cannot find -lrvsip
原来是radv没有编译,librvsip.a也没有生成。
cd radv
make
make install
此时librvsip.a以生成,其他的一切貌似很正常。
再次编译总的源码时仍然出错:
/opt/toolchains/uclibc-crosstools-gcc-4.2.3-3/usr/bin/../lib/gcc/mips-linux-uclibc/4.2.3/../../../../mips-linux-uclibc/bin/ld:skipping incompatible
...
/opt/toolchains/uclibc-crosstools-gcc-4.2.3-3/usr/bin/../lib/gcc/mips-linux-uclibc/4.2.3/../../../../mips-linux-uclibc/bin/ld: cannot find -lrvsip
仔细分析我的操作和出错提示,真相大白于天下:
此嵌入式系统cpu 的arch 是mips,而我 "cd radv; make; make install" 时默认的gcc 是系统系统自带的X86的gcc,与crosstools gcc对应的mips-linux-gcc 显然不同,在链接的时候,mips-linux-ld 还是回检查ld的对象(这里是librvsip.a啦)的arch格式啦,ld:skipping incompatible 就是不兼容,连接失败,故还是回报错 ld: cannot find -lxxx(这里是lrvsip啦)。
另外有的网友不是这样的情况,有的是32bit CPU 与 64bit CPU的区别。
总之,每一种不同架构的CPU都会对应不同的GCC 工具链。
建议:
在单独模块移植编译的时候,常常并不指定具体的嵌入式crosstools gcc, Makefile 中的 CC 是从上级Makefile中继承来的,这样单独编译可能会没有问题。但一旦在其他模块中链接了此模块的生成的binary文件,比如生成的库,自然就会出现链接错误。在修改Makefile的时候往往回加上install、clean等伪目标,install伪目标中执行的install或cp命令 一定要与clean伪目标执行的rm命令高度一致,更不可遗漏,clean的时候一定要clean掉install的binary文件。
另外,很多情况下使用共享库时并不是一帆风顺,比如执行程序的时候报类似下面的错误:
error while loading shared libraries: xxx.so.xx: cannot open shared object file: No such file or directory
一般的做法是:
I. 在/etc/ld.so.conf 或 /etc/ld.so.conf.d/xxx.conf( 比如本人的Fedora 10 ) 下 加 /usr/local/lib(比如本人装的 libpcap.so.1.3.0 在此目录)
II. root 权限下执行 ldconfig -v 使之马上生效,会有很多显示,如果不是root权限最后则会报错:
/sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
从这里可以看出,其原理是产生cache文件,loading shared libraries 的时候从cache中快速查找相应的目录和共享库(比如libpcap.so)。
//todo