The method of compiling and generating dynamic link library *.so file with gcc

Original address: /etc/ld.so.conf http://blog.sina.com.cn/s/blog_4cce4f6a0100ms6f.html File Author: Fang Ren also
    Linux Shared Libraries

　　There are two fundamentally different types of Linux executables on a Linux system . The first category is statically linked executable programs. Static executables contain all the functions needed to execute - in other words, they are "complete". For this reason, static executables can run without any dependencies on external libraries.

　　The second category is dynamically linked executable programs.
　　Comparing Static and Dynamic Executables

　　We can use the ldd command to determine whether a particular executable is statically linked:
　　# ldd /sbin/sln
　　not a dynamic executable
　　“not a dynamic executable” is ldd means sln is A way of static linking. Now, let's compare the size of sln with its non-static cousin ln:
　　# ls -l /bin/ln /sbin/sln
　　-rwxr-xr-x 1 root root 23000 Jan 14 00:36 /bin/ln
　　-rwxr-xr- x 1 root root 381072 Jan 14 00:31 /sbin/sln
　　As you can see, sln is ten times larger than ln. ln is so much smaller than sln because it is a dynamic executable. Dynamic executable programs are incomplete programs that rely on external shared libraries to provide many of the functions needed to run.
　　Dynamic Link Dependencies
　　To see a list of all shared libraries that ln depends on, use the ldd command:
　　# ldd /bin/ln
　　libc.so.6 => /lib/libc.so.6 (0x40021000)
　　/lib/ld-linux .so.2 => /lib/ld-linux.so.2 (0x40000000)
　　As you can see, ln depends on the external shared libraries libc.so.6 and ld-linux.so.2. Generally, dynamically linked programs are much smaller than their statically linked equivalents. However, statically linked programs can be useful in some low-level maintenance tasks. For example, sln is an excellent tool for modifying symlinks to different libraries located in /lib. But generally you will find that almost all executable programs on a Linux system are some variant of dynamic linking.
　　Dynamic Loaders
　　So , if dynamic executables don't contain all the functions needed to run, what part of Linux is responsible for loading these programs, along with all the necessary shared libraries, so that they can execute correctly? The answer is the dynamic loader, which is actually the ld-linux.so.2 library listed as a shared library dependency you see in ln's ldd manifest. The dynamic loader is responsible for loading the shared libraries that the dynamically linked executable program needs to run. Now, let's take a quick look at how the dynamic loader finds the appropriate shared library on the system.
　　ld.so.conf
　　The dynamic loader relies on two files to find shared libraries - /etc/ld.so.conf and /etc/ld.so.cache. If you cat the /etc/ld.so.conf file, you may see a listing similar to the following:
　　$ cat /etc/ld.so.conf
　　/usr/X11R6/lib
　　/usr/lib/gcc -lib/i686-pc-linux-gnu/2.95.3
　　/usr/lib/mozilla
　　/usr/lib/qt-x11-2.3.1/lib
　　/usr/local/lib
　　ld.so.conf file contains a all directories (except /lib and /usr/lib, which are automatically included) manifest where the dynamic loader will look for shared libraries.
　　ld.so.cache
　　but before the dynamic loader can "see" this information, it must be converted into the ld.so.cache file. You can do this by running the ldconfig command:
　　# ldconfig
　　When the ldconfig operation ends, you will have an up-to-date /etc/ld.so.cache file that reflects your changes to /etc/ld.so.conf . From this moment on, the dynamic loader looks at all new directories you specify in /etc/ld.so.conf when looking for shared libraries.
　　
　　ldconfig tricks
　　
　　To see all shared libraries that ldconfig can "see", type:
　　
　　# ldconfig -p | less
　　There is another handy trick you can use to configure the shared library path. Sometimes you want to tell the dynamic loader to try a shared library in a specific directory before trying any /etc/ld.so.conf paths. This is handy in cases where you're running an older application that doesn't work with the currently installed library version.
　　LD_LIBRARY_PATH
　　To instruct the dynamic loader to check a directory first, set the LD_LIBRARY_PATH variable to the directory you wish to search. Multiple paths are separated by colons; for example:
　　# export LD_LIBRARY_PATH="/usr/lib/old:/opt/lib"
　　After exporting LD_LIBRARY_PATH, all executable programs launched from the current shell will use /usr if possible Libraries in /lib/old or /opt/lib, if some shared library dependency requirements are still not met, fall back to the library specified in /etc/ld.so.conf.

http://blog.csdn.net/liuying_1001/article/details/6611106%5c


The way to convert from static library .a to dynamic library .so is as follows:

.a is a static library with a series of .o files packaged together by the ar program If you want to convert it into a dynamic library, you only need to unpack it first, generate a bunch of .o files, and then compile it into a dynamic library through a compiler (such as gcc or ifort, as the case may be).

ar -x libtest.a
gcc -shared *.o -o libtest.so

But it should be noted that:

(1) Not all .a can be converted into .so, provided that the .o file solved by .a contains "position independent code", if it does not, .so cannot be generated. "Position independent code" requires specifying the -fpic or -fPIC option when compiling the .a. So, if there is only one .a file and no corresponding source file and this .a contains no "position independent code", then it cannot be turned into a .so file.

(2) I think the same compiler should be used when generating .so as when generating .a. If it is different, I don't know if it will cause problems.




Huaxiamian Studio: http://huaxiamian.cc