Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "introduction to the usage of dynamic and static libraries in Linux". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Dynamic and static libraries in Linux (.a / .la / .so / .o)

Dynamic and static libraries in Linux (.a / .la / .so / .o)

The use of libtool

1. Create a Libtool object file

two。 Create a Libtool library

3. Install the Libtool library

4. Use the Libtool library

5. Uninstall the Libtool library

Create atoi.so

Use atoi.so

Create atoi.a

Use atoi.a

Create atoi.o

Use atoi.o

The process of compiling CAccord + Program

.o file (target file)

.a file (static library file)

.so file (shared library file)

.la file (libtool archive)

Under windows, the type of a file can generally be identified by its suffix name. It is also generally possible under Linux. But to be clear, under linux, the suffix of a file is not necessarily related to the type of file. It's just a habit known as an agreement.

The gcc compiler is generally used in the development of gcc + under linux, so the main explanation of this article is gcc.

O file, that is, the target file. It is generally compiled from .c or .cpp files, which is equivalent to the obj files compiled by VC.

.so file, shared object shared library (object), which is equivalent to dll under windows.

.a file, archive archive package, that is, static library. It is essentially the result of the packaging of multiple .o files, which is equivalent to the .lib file under VC.

La file, libtool archive file, is a shared library file automatically generated by libtool.

The four files are described one by one below.

The process of compiling CAccord + Program

First of all, let's talk about the process of compiling Cmax Craft +.

Preprocessing, expansion header file, macro definition, conditional compilation processing, etc. Generated by gcc-E source.c-o source.i or cpp source.c.

Compile. Here is a narrow sense of compilation, which refers to the process of translating preprocessed files into assembly code. Generated by gcc-S source.i. The source.s file is generated by default.

Compilation. The process of translating the assembly code generated in the previous step into the corresponding binary machine code. Generate the source.o file through gcc-c source.s.

Link. A link is the process of generating a complete executable program from the generated object file and the various symbols it references. Virtual memory redirection is performed when linking.

The above four steps are the basic steps for compiling the CumberCraft + program. The first three steps are simple and most of the time they are merged into one step. Only the link in the fourth step is a little more complex. In many cases, when we compile larger projects, we often report errors in the lack of some libraries when linking, or some symbols can not be defined, redefined, and so on.

.o file (target file)

The .o file is the result of the compilation of CumberCraft + source code. That is, the first three steps in the compilation process of CCompact + mentioned above. In general, these three steps are rarely done separately in general development, and the usual practice is to generate them in one step.

For example, let's write a function int atoi (const char* str).

Header file atoi.h

. # ifndef ATOI_H.#define ATOI_Hint atoi (const char* str);. # endif / /! ATOI_H

Source file atoi.c

. # include. # include "atoi.h" int atoi (const char* str) {int ret = 0; if (str! = NULL) {sscanf (str, "% d", & ret);} return ret;} create atoi.o

Use the command gcc-c atoi.c-o atoi.o or gcc-c atoi.c directly to generate the target file.

The above function calls sscanf, a function in the C standard library, so it will record this existence in the .o file, which we can use the readelf tool to check.

Total amount of 20drwxr-xr-x 2 o 4096 October 10 15:11. / drwxrwxr-x 5 1000 1000 October 10 14:32.. /-rw-rw-r-- 1 o 140 October 10 15:07 atoi.c-rw-rw-r-- 1 oo 75 October 10 15:07 atoi.h-rw-rw-r-- 1 oo 1536 October 10 15:11 atoi.oo@Neo-kylin:~/lib_a_so$ readelf-s atoi.o Symbol table '.symtab' contains 11 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000000000 0 FILE LOCAL DEFAULT ABS atoi.c 2: 00000000000000 0 SECTION LOCAL DEFAULT 1 3: 0000000000000000 0 SECTION LOCAL DEFAULT 3 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 5: 0000000000000000 0 SECTION LOCAL DEFAULT 5 6: 0000000000000000 0 SECTION LOCAL DEFAULT 7 7: 0000000000000000 0 SECTION LOCAL DEFAULT 8 8: 0000000000000000 0 SECTION LOCAL DEFAULT 6 9: 0000000000000000 60 FUNC GLOBAL DEFAULT 1 atoi 10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ _ isoc99_sscanf

This is the .o file. It holds the symbols (functions, global variables, etc.) that are referenced when compiling, which need to be used when linking.

Use atoi.o

There are many places to use atoi.o, so I won't list them one by one. Not to mention how to use it here, it will be used later when generating .a files.

.a file (static library file)

A static library is the result of the packaging of multiple .o files. As mentioned earlier, it is not necessary to have multiple files. A .o file can also be packaged as a .a file.

This step is done using the ar tool. The ar tool is used to create, modify and extract archives archives. For more information, please see manpages.

Ar [emulation options] [-] {dmpqrstx} [abcfilNoPsSuvV] [member-name] [count] archive-file file...

The function of this tool looks simple, but it is very powerful, and the parameter setting is very complex. The purpose of this is not to introduce this tool, so I won't go into details.

Create atoi.a

Let's first use the atoi.o file generated above to generate an atoi.a file.

Creating atoi.ao@Neo-kylin:~/lib_a_so$ ll 24drwxr-xr-x 2 oo 4096 October 10 15:35. / drwxrwxr-x 5 1000 1000 October 10 14:32.. /-rw-rw-r-- 1 oo 1678 October 10 15:35 atoi .a-rw-rw-r-- 1 o 140 October 10 15:07 atoi.c-rw-rw-r-- 1 o 75 October 10 15:07 atoi.h-rw-rw-r-- 1 o 1536 October 10 15:11 atoi.o

The-r parameter means to replace an existing file or insert a new file into the archive package.

Use atoi.a

Once we have created the atoi.a file, we can use it. Here we write a main function to call atoi.

Main.c file

Int main () {return atoi ("5");}

This time let's compile main.c into a main.o file first.

Ooh, Neolyk, Kylinghill, moxie, libregaiso, $lsatoi.an atoi.c atoi.h atoi.o main.co@Neo-kylin:~/lib_a_so$ gcc-c main.co@Neo-kylin:~/lib_a_so$ lsatoi.an atoi.c atoi.h atoi.o main.c main.o

Then use the ld program to link main.o and atoi.a

Mainld: warning: cannot find entry symbol _ start; defaulting to 00000000004000b0atoi.a (atoi.o): In function `atoi':atoi.c: (.text + 0x33): undefined reference to `_ _ isoc99_sscanf'`

An error is reported above because the undefined reference _ _ isoc99_sscanf is used in the atoi function. We can solve this problem by linking libc.an or libc.so. Usually, link libc.so to solve the problem, if you use glibc's static library, then you must also open source your program, otherwise this should be regarded as a violation of the GPL agreement.

Cannot find entry symbol Neomura Kylinghorn cannot find entry symbol start; defaulting to 00000000400288

Here is another warning that the _ start symbol is not found. This is because the main entry point of the program has not been found. In C language, the entry function of the program is main, but in assembly, the main entry function of the program is _ start.

Here we can change the main function in the main.c file to the _ start function, and then compile it to main.o and then link it. But this is not the right thing to do, although using ld to link will not report an error, but the program will not run. Errors will be reported.

There is no file or directory for that file or directory. / main-bash:. / main: / lib/ld64.so.1: bad ELF interpreter

The right thing to do is to link to many files such as crt0.o, crti.o, crtn.o and so on. Different machines may have different locations of the files that need to be linked. This parameter may be too long for ordinary people to remember.

How can I get this? I certainly don't know where these files are located, but the gcc compilation environment knows that we can use gcc to get them.

The built-in specs is used in the built-in specs for the built-in specs. Goal: x86_64-redhat-linux is configured as:.. / configure-- prefix=/usr-- mandir=/usr/share/man-- infodir=/usr/share/info-- with-bugurl= http://bugzilla.redhat.com/bugzilla-- enable-bootstrap-- enable-shared-- enable-threads=posix-- enable-checking=release-- with-system-zlib-- enable-__cxa_atexit-- disable-libunwind-exceptions-- enable-gnu-unique-object-- enable-languages=c,c++,objc,obj-c++,java,fortran Ada-enable-java-awt=gtk-disable-dssi-with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre-enable-libgcj-multifile-enable-java-maintainer-mode-with-ecj-jar=/usr/share/java/eclipse-ecj.jar-disable-libjava-multilib-with-ppl-with-cloog-with-tune=generic-with-arch_32=i686-build=x86_64-redhat- Linux line Program model: posixgcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/ X86xx6xxxcxx86xxx6xxxx6xxxx6xxx6xxx6xxx6xxx6xxx6xx6xx6fcxx86xxx6xxx6xxx6uxlntredhatlinguxGREGRETHART LIBRARYPATHANGGccUnix Redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../:/lib/:/usr/lib/COLLECT_GCC_OPTIONS='-v''- o 'main''-mtune=generic' / usr/libexec/gcc/x86_64-redhat-linux/4.4.7/collect2-- eh-frame-hdr-- build-id-m elf_x86_64-- hash-style=gnu-dynamic-linker / lib64/ld-linux-x86-64.so.2-o main / usr/lib/gcc/x86_64-redhat-linux/4.4.7/../lib64/crt1.o / usr/lib / gcc/x86_64-redhat-linux/4.4.7/../lib64/crti.o / usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbegin.o-L/usr/lib/gcc/x86_64-redhat-linux/4.4.7-L/usr/lib/gcc/x86_64-redhat-linux/4.4.7-L/usr/lib/gcc/x86_64-redhat-linux/4 .4.7 /.. / lib64-L/lib/../lib64-L/usr/lib/../lib64-Lancet usr Universe libUnique gccUnix x86aft 64 Quartet Redhat LinuxUnix 4.4.7... Main.o atoi.a-lgcc-as-needed-lgcc_s-no-as-needed-lc-lgcc-as-needed-lgcc_s-no-as-needed / usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtend.o / usr/lib/gcc/x86_64-redhat-linux/4.4.7/../lib64/crtn.o

After compilation, we can see whether the following program runs correctly.

Main Neomura Kylinghill lump echo $? 5

The result was 5, as expected.

.so file (shared library file)

The concept of the shared library file is the same as the dll file (dynamic link library) under windows, which is dynamically linked while the program is running and can be called by the program.

Under linux, you can use the ldd command to see which shared libraries (dynamic libraries) need to be linked to an executable file, and to determine the location of these shared libraries to be linked locally.

0x000000305d800000 / 0x000000305d800000 / lib64/ld-linux-x86-64.so.2 (0x000000305d000000)

Here is the search path for the following dynamic libraries. For the dynamic library xxx.so that the program needs to link, if it is in the current directory, link the one in the current directory. If not, link the path to look for xxx.so in the system / etc/ld.so.cache (which can be updated through ldconfig) file, and if none, an error will be reported.

Let's create a libc.so.6 file in the current directory and then take a look at it using ldd.

Chmod + x libc.so.6o@Neo-kylin:~/lib_a_so$ ls-l libc.so.6-rwxrwxr-x 1 oo 0 October 10 17:15 libc.so.6o@Neo-kylin:~/lib_a_so$ ldd main./main: error while loading shared libraries:. / libc.so.6: file too short

As you can see, this is the libc.so.6 file in the current directory of the link, but unfortunately, something went wrong.

In fact, when linking, we can use-Wl,-rpath=sopath to specify the path to load the dynamic library at run time. The advantage of this is that the location information of some dynamic libraries can not be added to the / etc/ld.so.cache, which has avoided conflicts with the existing dynamic libraries of the system. (for example, the glibc library version of the target machine is too low, while the program is compiled with a high version, and an error similar to "libc.so.6: version `GLIBC_2.14' not found" occurs)

Note:-Wl: indicates that the following parameters will be passed to the link program ld,gcc compile-time link is actually called ld.

Create atoi.so

Here again, use the atoi.c file you created earlier to create the atoi.so file. We actually create the atoi.so.1 file here, and the. 1 after the file name represents the version number. Because the dynamic library is dynamically linked when used, rather than directly linked to the target program file. So there may be multiple versions at the same time, and the version number is generally specified.

Usually use libxxx.so. The main version number. Name it in the form of a minor version number.

Atoi.so.1 atoi.c/usr/bin/ld: / tmp/ccLK0pLC.o: relocation R_X86_64_32 against `.rodata 'can not be used when making a shared object Recompile with-fPIC/tmp/ccLK0pLC.o: could not read symbols: Bad valuecollect2: ld returns 1o gcc Neomuri Kylinghill moonlight atoi.so.1 atoi.co@Neo-kylin:~/lib_a_so$ lsatoi.an atoi.c atoi.h atoi.o atoi.so.1 main.c main.o

-share this option specifies that a dynamic link library is generated (let the connector generate T-type export symbol tables and sometimes weak-link W-type export symbols, which will be discussed later when the nm tool is introduced), without this sign that external programs cannot connect. Is equivalent to an executable file.

-fPIC means that the compiled code is location-independent. Without this option, the compiled code is location-dependent, so dynamic loading is to copy the code to meet the needs of different processes, rather than the real sharing of code snippets.

An error occurred when the-fPIC was not specified for the first time, because for the portable R_X86_64_32 platform, the read-only data segment '.rodata' could not be created into a shared object, because when dynamically linking a dynamic library, if it was not compiled into location-independent code, an error may occur during execution because the location of some code is relevant. When linked, the executable knows where each line of code and each variable will be placed in the linear address space, so these addresses can be written into the code as constants. For dynamic libraries, you only know when they are loaded.

If there are no read-only segments in the code, there will be no problem. For example

Val.so val.c val.so val.c gcc-shared-o val.so val.c use atoi.so

Using .so files is similar to using .a, and ld is also used for linking. Because this is too complex, use gcc to do this (in fact, gcc also uses ld).

0x00007fff56eaf000 atoi.so.1 = > not found libc.so.6 = > / lib64/libc.so.6 (0x000000305d800000) / lib64/ld-linux-x86-64.so.2 (0x000000305d000000). / lib64/libc.so.6 / 64.so.2 (0x000000305d000000). / main. / main: Error while loading shared libraries: atoi.so.1: cannot open shared object file: No such file or directory

An error was reported during the execution above, which means that the file atoi.so.1 could not be found. The reason is that the lookup directory of the shared library does not have the current directory, so we can add the environment variable LD_LIBRARY_PATH to make the system dynamic loader (dynamic linker/loader) also look in the current directory.

0x000000305d800000 / lib64/ld-linux-x86-64.so.2 (0x000000305d000000) / lib64/libc.so.6 Neomurkylinmoso / libsuso export LD_LIBRARY_PATH=.o@Neo-kylin:~/lib_a_so$ ldd main linux-vdso.so.1. / atoi.so.1 (0x00007f9ed7ac6000) libc.so.6 = > / lib64/libc.so.6 (0x000000305d800000) / lib64/ld-linux-x86-64.so.2 (0x000000305d000000). / main Othing Neofukylinghanghuanghuanghuo libangaiso $echo $? 5

Another way, which is better and more portable than adding environment variables, is to specify the load path of the runtime shared library at compile time. Gcc is specified with-Wl,-rpath=sopath, where sopath is the path (either absolute or relative) where the shared library is placed.

Ooh Neomuri Kylinghorn Wl,-rpath=. paste libretaiso $gcc-o Kylinman-Wl,-rpath=. Atoi.so.1 oft Neolyn Kylinmoso hookups $ldd main linux-vdso.so.1 = > (0x00007fff457ff000) atoi.so.1 = >. / atoi.so.1 (0x00007fb946d56000) libc.so.6 = > / lib64/libc.so.6 (0x000000305d800000) / lib64/ld-linux-x86-64.so.2 (0x000000305d000000) osuch Neolym kylinlas lump libarians so $. / main ohmic Neolyphs kylinria lingers $echo $? 5

Dynamic libraries can also be used through dlopen/dlsym and so on, which will not be covered here.

.la file (libtool archive)

For the following, refer to creating a library using GNU Libtool

First of all, let's talk about the following libtool tool.

Libtool is an overly complex tool for GNU to solve the different operations of creating dynamic / static library files on different platforms. It provides a way to use abstract interfaces for dynamic / static libraries.

Using GNU Libtool, you can easily build dynamic link libraries in different systems. It hides the differences between different systems and provides developers with a consistent interface through an abstraction called the Libtool library. In most cases, developers don't even have to check the corresponding system manual, they just need to master the usage of GNU Libtool. Also, Makefile using Libtool only needs to be written once to be used on multiple systems.

The use of libtool

The use of libtool is generally divided into the following steps

1. Create a Libtool object file

two。 Create a Libtool library

3. Install the Libtool library

4. Use the Libtool library

5. Uninstall the Libtool library

1. Create the Libtool object file: gcc Neomurkylinvell object file-- mode=compile gcc-c atoi.c libtool: compile: gcc-c atoi.c-fPIC-DPIC-o .libs / atoi.olibtool: compile: gcc-c atoi.c-o atoi.o > / dev/null 2 > & 1ofuromai kylinghanaganxuxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx .. Atoi.an atoi.c atoi.h atoi.lo atoi.o .libs main main.c main.lo main.o./.libs:. .. Atoi.o libatoi.a libatoi.la libatoi.lai libatoi.so libatoi.so.0 libatoi.so.0.0.0 main.o

The process of creating a libtool object file is actually a process of generating .o, .so, and .a files, as well as a .lo file. The .lo file describes the paths of the two .o files. At this step, the corresponding dynamic and static libraries have been generated.

2.2.6b## Please DO NOT delete this 2.2.6b## Please DO NOT delete this filter # It is necessary for linking the library.# Name of the PIC object.pic_object='.libs/atoi.o'# Name of the non-PIC objectnon_pic_object='atoi.o' # atoi.lo-a libtool object file# Generated by ltmain.sh (GNU libtool)

One of them is used to generate static libraries and the other is used to produce dynamic libraries.

two。 Create the Libtool library: libtool-- mode=link gcc-o libatoi.la atoi.lo-rpath / home/o/lib_a_so/lib-lclibtool: link: rm-fr .libs / libatoi.a .libs / libatoi.la .libs / libatoi.lai .libs / libatoi.so / libatoi.so.0 .libs / libatoi.so.0.0.0libtool: link: gcc-shared .libs / atoi.o-lc-Wl,-soname-Wl Libatoi.so.0-o. Libs / libatoi.so.0.0.0libtool: link: (cd ".libs" & & rm-f "libatoi.so.0" & & ln-s "libatoi.so.0.0.0"libatoi.so.0") libtool: (cd ".libs" & & rm-f "libatoi.so" & & ln-s "libatoi.so.0.0.0"libatoi.so") libtool: link: ar cru .libs / libatoi.an atoi.olibtool: link: ranlib .libs / libatoi.alibtool: link: (cd ".libs" & & rm-f "libatoi.la" & & ln-s ".. / libatoi.la"libatoi.la")

Note that atoi.lo is used as the input file here, and the generated target file is specified as libatoi.la.

The-rpath option specifies where Libtool installs the library, and if the-rpath option is omitted, no dynamic-link library is generated.

Because the standard C library function sscanf is used in the atoi function, with the-lc option, Libtool will remember this dependency and automatically link the dependent library in later when using our library.

Ooh Neomuri Kylinghill mock libregaiso $ls-aR.:. .. Atoi.an atoi.c atoi.h atoi.lo atoi.o libatoi.la .libs main main.c main.lo main.o./.libs:. .. Atoi.o libatoi.a libatoi.la libatoi.lai libatoi.so libatoi.so.0 libatoi.so.0.0.0 main.o

You can see that this time the libatoi.la file is generated in the current directory, and the one in the .libs directory is a symbolic link to the file in the current directory. This is actually a text file, in which the content is relatively long, so it will not be posted. Post some more important ones.

Ooh, Neo, Kylinghill, cat libatoi.la dlname='libatoi.so.0'library_names='libatoi.so.0.0.0 libatoi.so.0 libatoi.so'old_library='libatoi.a'dependency_libs=', lc'installed=noshouldnotlink=nodlopen=''dlpreopen=''libdir='/home/o/lib_a_so/lib'3, etc. Install the Libtool library: libatoi.so.0.0.0 Neomurkylin / libatoi.so.0.0.0 / home/o/lib_a_so/libatoi.so.0.0.0libtool: libtool-- mode=install install-c libatoi.la / home/o/lib_a_so/liblibtool: install: cd / home/o/lib_a_so & & {ln-s-f libatoi.so.0.0.0 libatoi.so.0 | {rm- F libatoi.so.0 & & ln-s libatoi.so.0.0.0 libatoi.so.0 };}) libtool: install: (cd / home/o/lib_a_so & & {ln-s-f libatoi.so.0.0.0 libatoi.so | | {rm-f libatoi.so & & ln-s libatoi.so.0.0.0 libatoi.so;} }) libtool: install: install-c. Libs / libatoi.lai / home/o/lib_a_so/libatoi.lalibtool: install: install-c. Libs / libatoi.a / home/o/lib_a_so/libatoi.alibtool: install: chmod 644 / home/o/lib_a_so/libatoi.alibtool: install: ranlib / home/o/lib_a_so/libatoi.alibtool: install: warning: remember to run `libtool-- finish / home/o/lib_a_so/lib'

The above operation reports a warning that prompts us to run libtool-- finish / home/o/lib_a_so/lib. This operation is the process of using libtool to correctly configure environment variables such as LD_LIBRARY_PATH, LD_RUN_PATH, and so on. If you cannot use the installed library properly, run this command.

Ls check and see that the files libatoi.a, libatoi.so, libatoi.so.0, and libatoi.so.0.0.0 are generated in the current directory.

There is a lot of money in it. It's a lsatoi.an atoi.c atoi.h atoi.lo atoi.o libatoi.a libatoi.la libatoi.so libatoi.so.0 libatoi.so.0.0.0 main main.c4. Use the Libtool library

Compile the main.c file first

Gcc Neomura Kylinmoso / main.olibtool: compile: gcc-c main.c-o main.o > / dev/null 2 > & 1

Then use Libtool to do the linking operation.

Library: home/o/lib_a_so/libatoi.la' was moved.libtool: link: warning: library `/ home/o/lib_a_so/libatoi.la' was moved.libtool: link: gcc-o main .libs / main.o / home/o/lib_a_so/libatoi.so-lc-Wl,-rpath-Wl / home/o/lib_a_so-Wl,-rpath-Wl,/home/o/lib_a_so

As you can see from the output above, it's actually a called gcc to do the operation, but it adds the option-lc, which is one of the things Libtool does, which solves the dependency problem.

Echo echo $lsatoi.an atoi.h atoi.o libatoi.la libatoi.so.0 main main.loatoi.c atoi.lo libatoi.a libatoi.so libatoi.so.0.0.0 main.c main.oo@Neo-kylin:~/lib_a_so$. / main color Neofurou Kylinlu lump LBQ $LBM $?

The above operation uses dynamic libraries by default, and you can use the-static-libtool-libs option to specify the use of static libraries.

Olympian Neomurafe Kylinghorn / lib64/ld-linux-x86-64.so.2 (libatoi.so.0) > (0x00007fffd3bff000) libatoi.so.0 = > / home/o/lib_a_so/libatoi.so.0 (0x00007f984bdd0000) libc.so.6 = > / lib64/libc.so.6 (0x000000305d800000) / lib64/ld-linux-x86-64.so.2 (0x000000305d000000)

Regenerate using the-static-libtool-libs option.

Library: link: warning: library `/ home/o/lib_a_so/libatoi.la' was moved.libtool: link: gcc-o main .libs / main.o / home/o/lib_a_so/libatoi.a-lc

Libatoi.so.0 is no longer needed.

0x000000305d800000 / 0x000000305d800000 / lib64/ld-linux-x86-64.so.2 (0x000000305d000000) 5. Uninstall the Libtool library

This is an inverse operation to the installation operation and deletes all installed library files.

The movement in the Linux of mode=uninstall rm / home/o/lib_a_so/libatoi.la libtool: uninstall: rm / home/o/lib_a_so/libatoi.la / home/o/lib_a_so/libatoi.so.0.0.0 / home/o/lib_a_so/libatoi.so.0 / home/o/lib_a_so/libatoi.so / home/o/lib_a_so/libatoi.a This is the end of the introduction to the usage of state library and static library. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.