About the library files under Linux __linux

Let's talk about how the library file came in.

Take C as an example, we write a program, generally not all of the functions are written in a file, is usually divided into modules, and then a module several files, and then in the main file to call these modules. I'm using a magic.c file instead of all the files in the actual program, and you're going to be very magical about this magic.c file, and after you call the Magic () function, it automatically completes the rest of your work as you think. Here are two files:

Mian.c

int main () {
  magic ();
}

MAGIC.C:

#include <stdio.h>
void Magic () {
  printf ("This is a magic function\n");
}

MAIN.C file does not include any header files, because our compilation is manually steps, the actual code does not recommend this, here you can more clearly know the role of the header file.

Generally from C source file to executable code to go through the following 4 steps: Precompiled (Preprocess gcc-e, generate. i file), compile (compile gcc-s, generate. S file), assemble (assemble gcc-c, generate. o files), link Build the executable file). Here we only discuss the last two steps, compilations and links.

The result of the Assembly is that each source file has a corresponding binary code; The link is to package all the binaries into one file and finally get the executable file.

Use this command to assemble main.c:gcc-wall-c MAIN.C

-wall is the switch that lists the warning, if there is no this switch, the assembly is successful, no hint, and if you turn on this switch, you will get the following warning:

Main.c:2:3:warning:implicit declaration of function ' magic ' [-wimplicit-function-declaration]

To eliminate this warning is easy, there are two ways:

1 before adding a declaration on the good, void Magic ();

2 Write a magic.h header file:

void Magic ();

It is then included in the MAIN.C: #include "magic.h".

The effect of both approaches is to tell main that there is no magic implementation, and I'm sure that the magic function is there and that it's safe to use, and it tells the main how to use the magic, what the parameters are, what the return value is.

But there is no magic statement, just a warning, not a mistake, because we know how our magic is defined, and we are sure to link the Magic function later.

But here's the thing, like we wrote a super-awesome function for someone else to use, but this super-awesome function is going to do it next week. We can give the head file first, then pat the chest and say you write according to my function declaration, as long as your call is no problem, the result of the program running is no problem.

It's a week before we can give someone our super power function, and we have two options to choose from.

First, the source of the file, this is not to say, it is great, learn from each other progress, let others themselves into the original file into binary code, and then and his main code to link to executable code is good.

Second, if it involves commercial or copyright factors, then we can only give the compiled binary code to others, and then let others go to the link. Here also embodies the benefits of the header file, just need to know how to call the function can be, do not have to know how to write inside the function. For example, just start learning C just need to know how to use fopen, fclose, fprintf, fscanf, and so on, and then slowly go deep again to find out.

OK, so what is the library file? In fact, the compiled binary code, is written by someone else's super awesome code after the compilation put there for us to use. But this compiled binary code is a little different from what we've generated, specifically, in two ways.

The library file itself is divided into two types: the static library file (dynamic Library), the static library file, and Linux, where the archive is terminated with a. A (a), and the dynamic library file ends with. So (Shared object).

A static library file is actually a compressed file (archive) of the compiled binary code, which can have one or N. o files. Like the magic.c above, you can generate a static library file like this:

First Assemble: gcc-c magic.c, Generate MAGIC.O, and then use compressed File command (AR) to generate static library files: AR rc libmagic.a magic.o, where RC is the compression option, LIBMAGIC.A is the name of the static library file, MAGIC.O is used to generate a static library file binaries, of course, can be followed by many. o files, compressed them into a static library file for others to use.

LIBMAGIC.A will be ready to link with main binary file: Gcc-o main main.o-lmagic-l.

The-o main option is to name the resulting executable file as main, and if not, the default name is A.out,-lmagic, which means using the. so file libmagic.so (described later) or LIBMAGIC.A, if all exist. There is no libmagic.so file yet, so it links the magic function inside the LIBMAGIC.A.

Dynamic library files are somewhat different, directly using GCC generation, first or assembly: Gcc-fpic-c MAGIC.C, because the compiled binary code to be used as a dynamic library, so there is a-fpic option to determine the location of the links in the library functions. The dynamic library file is then generated from the binary file: Gcc-shared-o libmagic.so magic.o. A lot of. o files can be followed.

Dynamic libraries are linked to the same commands as static libraries, but do things differently. Link Static library file is to copy the functions inside the library into the executable file, so the executable file generated after the static library file is not important. The dynamic link simply records the dynamic library file that the function needs to use in the executable file. The real link is running (run), only running our generated executable file, to use the dynamic library file inside the function, the function will be loaded into memory and then executed. So it involves the path problem of the operating system looking for the dynamic link library. You can use the LDD program to see which dynamic library files Our programs use: LDD Main, the output is as follows:

Linux-vdso.so.1 => (0x00007fff8c9dd000)

Libmagic.so => not found

Libc.so.6 =>/lib/x86_64-linux-gnu/libc.so.6 (0x00007fb0f846c000)

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

You can see that libmagic.so is not found, so if you run main, you will also receive an error:./main:error while loading shared libraries:libmagic.so:cannot open Shared object F Ile:no such file or directory. To have the system locate the dynamic library file, you must set the path of the dynamic library file (unlike executable path path, header file path include OH), if you want to add the current path to the search path of the dynamic library file, you can set the following:

Ld_library_path= $LD _library_path:. /* Current path is. */

Export Ld_library_path

After setting the path, the dynamic library file can be found, then run LDD Main, output the following results:

Linux-vdso.so.1 => (0x00007fffb55ff000)

Libmagic.so (0x00007ff515fa7000)

Libc.so.6 =>/lib/x86_64-linux-gnu/libc.so.6 (0x00007ff515bec000)

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

About the link to say a little more, gcc link is called another program: LD. You can manually call the LD yourself or write it in the makefile, but generally you don't have to bother with GCC.

Because the link method is not used, so the executable file linked to the static library file is generally relatively large, such as the above example, the link static library file after the main size is 8,498 bytes, and the link dynamic library file after the size of main is 8401 bytes. As if the file size is not less, that is because our magic function is small, a big difference is very obvious.

Thank you for watching, welcome to comment.

Reference documents:

The art of debugging with GDB,DDD, and Eclipse. Norman Matloff and Peter Jay Salzman.