Linux. o ,. so ,. a ,. the file type in Linux does not depend on its suffix, but generally speaking :. o is the target file, which is equivalent. obj file. so is a shared library and is a shared object for dynamic connection, similar to dll. a is a static library, and there are many. o is used together for static connections. la is a shared library automatically generated by libtool. It is edited and viewed by vi and mainly records some configuration information. You can run the following command to view the format of the file $ file *. la *. la: ASCII English text in www.2cto.com *. la. Therefore, you can use vi to view its content. @ Create. library a files and. o library file: [yufei @ localhost perl_c2] $ pwd/home/yufei/perl_c2 [yufei @ localhost perl_c2] $ cat mylib. c # include <stdio. h> # include <string. h> void hello () {printf ("success call from perl to c library \ n");} [yufei @ localhost perl_c2] $ cat mylib. h extern void hello (); [yufei @ localhost perl_c2] $ gcc-c mylib. c [yufei @ localhost perl_c2] $ dir mylib. c mylib. h mylib. O [yufei @ localhost perl_c2] $ ar-r mylib. a mylib. o ar: Creating mylib. a [yufei @ localhost perl_c2] $ dir mylib. a mylib. c mylib. h mylib. o @ 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111 www.2cto.com dynamic link library *. so compilation and use--dynamic library *. so is often encountered in c and c ++ programming in Linux. Recently, I have found several articles on the website to introduce the compilation and linking of dynamic libraries, I have finally understood this topic that I have never been familiar with before. I am taking a note here, and I am also worried about other brothers who are worried about the dynamic Library Link Library. Provide some help. 1. The following is an example of how to generate a dynamic library. Here is a head file: so_test.h, three. c files: test_a.c, test_ B .c, and test_c.c. We compile these files into a dynamic library: libtest. so. So_test.h: # include <stdio. h> # include <stdlib. h> void test_a (); void test_ B (); void test_c (); test_a.c: # include "so_test.h" void test_a () {printf ("this is in test_a... \ n ");} test_ B .c: # include" so_test.h "void test_ B () {printf (" this is in test_ B... \ n ");} www.2cto.com test_c.c: # include" so_test.h "void test_c () {printf (" this is in test_c... \ n ") ;}compile these files into a dynamic library: libtest. so $ gcc test_a.c te St_ B .c test_c.c-fPIC-shared-o libtest. so 2. the link to the dynamic library is in 1. We have successfully generated a dynamic link library libtest. so, we will use a program to call the functions in this library. The source file of the program is test. c. Test. c: # include "so_test.h" int main () {test_a (); test_ B (); test_c (); return 0 ;}l will test. c. Dynamic library libtest. so link to generate the execution file test: $ gcc test. c-L. -ltest-o test l is used to test whether the libtest is dynamically connected. so, the connection is normal. $ ldd test l executes test and you can see how it calls functions in the dynamic library. 3. The most important option for parsing compilation parameters is the GCC command line option:-shared this option specifies to generate a dynamic Connection Library (let the connector generate a T-type export symbol table, sometimes, an exported symbol of the weak connection W type is generated. External programs cannot connect without this symbol. Equivalent to an executable file l-fPIC: code that is compiled into a separate location, if this option is not used, the compiled code is location-related. Therefore, during dynamic loading, the code is copied to meet the needs of different processes, rather than truly sharing code segments. L-L.: indicates that the library to be connected is in the current directory l-ltest: the compiler has an implicit naming rule when searching for a dynamic connected library, that is, add lib before the given name, and then add. so to determine the library name l LD_LIBRARY_PATH: This environment variable indicates that the dynamic connector can load the path of the dynamic library. L of course, if you have the root permission, you can modify/etc/ld. so. conf file, and then call/sbin/ldconfig to www.2cto.com for the same purpose. However, if you do not have the root permission, you can only use the LD_LIBRARY_PATH output method. 4. Pay attention to several issues that may occur frequently when calling a dynamic library. Sometimes, the directory where the header file of the library is already included through "-I, the file where the library is located is guided by the "-L" parameter and the database name of "-l" is specified. However, when you run the ldd command to view the file, you cannot find the so file with the specified link, in this case, you need to modify LD_LIBRARY_PATH or/etc/ld. so. conf file to specify the directory of the dynamic library. This usually solves the problem that the database cannot be linked. In makefile, how does one correctly compile and connect to generate the. so library file, and then how to compile and connect in The makefile of other programs to call the function of this library file ???? A: You need to tell the dynamic linker and loader ld. so where can I find this shared library? You can set the environment variables to add the library path to the library directory/lib and/usr/lib, LD_LIBRARY_PATH = $ (pwd ), this method is not convenient to use the command line method, A replacement method ^ ^ ^ LD_LIBRARY_PATH can be found in/etc/profile or ~ /. Profile or. /bash_profile, or. in bashrc, run source/etc/profile or. /etc/profile is better to add/etc/ld. so. conf, then run/sbin/ldconfig ^ ^ ^ adds the library path to/etc/ld. so. and then run ldconfig as root. You can also specify the file path and name-I-L during connection. GCC = gcc CFLAGS =-Wall-ggdb-fPIC # CFLAGS = all: libfunc test libfunc: func. o func1.o $ (GCC)-shared-Wl,-soname, libfunc. so.1- O libfunc. so.1.1 $ <ln-sf libfunc. so.1.1 libfunc. so.1 ln-sf libfunc. so.1 libfunc. so *************************************** ******************************* * **************** ln-s is used to create soft links, it is equivalent to a shortcut in windows. In the current directory, the command for creating the file www.2cto.com ttt in the upper-level directory named ttt2 soft link is ln-s .. /ttt ttt2. If the original file is deleted as the ttt file, ttt2 becomes an empty file. Ln-d is used to create a hard link, which is equivalent to a copy of a file in windows. When the original file is deleted, the content of the "copy" is not affected. When compiling the target file, use the-fPIC option of gcc to generate location-independent code and load it to any address: gcc-fPIC-g-c liberr. c-o liberr. o use the-shared and-soname options of gcc; use the-Wl option of gcc to pass the parameter to the connector ld; use the-l option of gcc to display the connection C library, to ensure that the required startup code can be obtained, so as to prevent programs from starting and running on systems that may be incompatible with the C library. Gcc-g-shared-Wl,-soname, liberr. so-o liberr. so.1.0.0 liberr. o-lc establishes a symbolic connection: ln-s liberr. so.1.0.0 liberr. so.1; ln-s liberr. so.1.0.0 liberr. so; In MAKEFILE: $ @ indicates the target file set in the rule. In a pattern rule, if there are multiple targets, "$ @" is the set that matches the schema definition in the target. $ % Indicates the target member name in the rule only when the target is in the function library file. For example, if a target is "foo. a (bar. o) ", then," $ % "is" bar. o "," $ @ "is" foo. a ". If the target file is not a function library file ([. a] in Unix and [. lib] in Windows), the value is null. $ <Name of the first target in the dependency target. If the dependency target is defined in the mode ("%"), "$ <" is a series of files that conform to the model. Note that it is obtained one by one. $? A set of new dependent targets. Separated by spaces. $ ^ A collection of all the dependent targets of www.2cto.com. Separated by spaces. If there are multiple duplicates in the dependency target, the variable removes the re-occurrence dependency target and retains only one copy. **************************************** ********************************** ************************************ Test: test. o libfunc $ (GCC)-o test. o-L. -lfunc %. o: %. c $ (GCC)-c $ (CFLAGS)-o $ @ $ <clean: rm-fr *. o rm-fr *. so * rm-fr test to be generated. so file, cc must contain the-shared parameter; to call. so files, such as libfunc. so, you can add-lfunc at the end of the cc command, and add-L/usr/xxx to indicate libfunc. so path. In this way, you can call libfunc in the source file to be compiled. so the function of this library file. I mentioned above. I 'd like to remind you that it is best to provide an interface header file for dynamic loading, using dlopen, dlclose, dlsym author johnny710vip.