Embedded compile-time Ld:cannot find-lxxx and ld:skipping incompatible

Compile source code times wrong:

/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

The original is radv did not compile, Librvsip.a also did not generate.

CD RADV

Make

Make install

At this point librvsip.a to build, everything else seems to be normal.

There are still errors when compiling the total source code again:

/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

Careful analysis of my operation and error tips, the truth of the World:

This embedded system CPUs The arch is MIPS, while I "CD radv;" Make The default gcc for make install is the X86 gcc from the system system, which is obviously different from the mips-linux-gcc of Crosstools gcc, when the link is mips-linux-ld Or check the LD object (here is Librvsip.a) arch format, ld:skipping incompatible is incompatible, connection failed, so or return wrong Ld:cannot find-lxxx (here is Lrvsip).

Another netizen is not such a situation, some 32bit CPU and 64bit CPU difference.

In short, each of the different architectures of the CPU will correspond to different GCC tool chains.

Suggestions:

When a standalone module is ported for compilation, it is often not specified that specific embedded crosstools gcc is used, and the CC in Makefile is inherited from Superior Makefile, so that separate compilation may be fine. But once the generated binary files of this module are linked in other modules, such as the generated libraries, there is a natural link error. When modifying makefile often back to add install, clean and other pseudo target, install pseudo target in the install or CP command must be executed with clean pseudo target RM command is highly consistent, and not to be omitted, When clean, be sure to clean off the install binary file.

In addition, it is not easy to use shared libraries in many situations, such as when executing a program that is similar to the following error:

Error while loading shared Libraries:xxx.so.xx:cannot open Shared object file:no such file or directory

The general practice is:

I. Add/usr/local/lib under/ETC/LD.SO.CONF or/etc/ld.so.conf.d/xxx.conf (such as my Fedora 10) (for example, I installed libpcap.so.1.3.0 in this directory)

II. root permission to execute ldconfig-v to take effect immediately, there will be a lot of display, if not root permissions will be the last error:

/sbin/ldconfig:can ' t create temporary cache file/etc/ld.so.cache~: Permission denied
It can be seen from here that the principle is to generate cache files, loading shared libraries from the cache to quickly find the appropriate directory and shared library (such as libpcap.so).

Todo