Differencebetween .So and .A Files

what is the difference between .so and .a files?

But it appears that even .a is shared library

Nope, it's a static library.

and can be used just like a .so lib

If you mean linking to it, then yes. But you can't dlopen() an .a file which you could do with an .so file.

You can always ask our old friend Uncle G to answer your questions.

What are .a and .so files?

Archive libraries (.a) are statically linked i.e when you compile your program with -c option in gcc. So, if there's any change in library, you need to compile and build your code again.

The advantage of .so (shared object) over .a library is that they are linked during the runtime i.e. after creation of your .o file -o option in gcc. So, if there's any change in .so file, you don't need to recompile your main program.
But make sure that your main program is linked to the new .so file with ln command.

This will help you to build the .so files.
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

Difference between .so file and .a file?

Basically the static library can be compiled into another application at link time. In your example Apache could use libcrypto.a during build time and include it in the Apache httpd application.

A dynamic .so library can be loaded and unloaded at runtime and you have a better flexibility to change what Apache should support without recompiling the Apache binaries.

Using Apache as example the dynamic loading of .so files are described in the Dynamic Shared Object (DSO) section in the documentation. You can also find links to the installation section which describe how to include static libraries at build time.

There is a good question about this that could be good to read, and that provide mote details in the subject.

Difference between shared objects (.so), static libraries (.a), and DLL's (.so)?

I've always thought that DLLs and shared objects are just different terms for the same thing - Windows calls them DLLs, while on UNIX systems they're shared objects, with the general term - dynamically linked library - covering both (even the function to open a .so on UNIX is called dlopen() after 'dynamic library').

They are indeed only linked at application startup, however your notion of verification against the header file is incorrect. The header file defines prototypes which are required in order to compile the code which uses the library, but at link time the linker looks inside the library itself to make sure the functions it needs are actually there. The linker has to find the function bodies somewhere at link time or it'll raise an error. It ALSO does that at runtime, because as you rightly point out the library itself might have changed since the program was compiled. This is why ABI stability is so important in platform libraries, as the ABI changing is what breaks existing programs compiled against older versions.

Static libraries are just bundles of object files straight out of the compiler, just like the ones that you are building yourself as part of your project's compilation, so they get pulled in and fed to the linker in exactly the same way, and unused bits are dropped in exactly the same way.

What exactly is in a .o / .a / .so file?

You're pretty much correct in the general idea for object files. In the "table that specifies at which addresses in the file" I would replace "addresses" with "offsets", but that's just wording.

.a files are simply just archives (an old format that predates tar, but does the same thing). You could replace .a files with tar files as long as you taught the linker to unpack them and just link with all the .o files contained in them (more or less, there's a little bit more logic to not link with object files in the archive that aren't necessary, but that's just an optimization).

.so files are different. They are closer to a final binary than an object file. An .so file with all symbols resolved can at least theoretically be run as a program. In fact, with PIE (position independent executables) the difference between a shared library and a program are (at least in theory) just a few bits in the header. They contain instructions for the dynamic linker how to load the library (more or less the same instructions as a normal program) and a relocation table that contains instructions telling the dynamic linker how to resolve the external symbols (again, the same in a program). All unresolved symbols in a dynamic library (and a program) are accessed through indirection tables which get populated at dynamic linking time (program start or dlopen).

If we simplify this a lot, the difference between objects and shared libraries is that much more work has been done in the shared library to not do text relocation (this is not strictly necessary and enforced, but it's the general idea). This means that in object files the assembler has only generated placeholders for addresses which the linker then fills in, for a shared library the addresses are filled in with addresses to jump tables so that the text of the library doesn't need to get changed, only a limited jump table.

Btw. I'm talking ELF. Older formats had more differences between programs and libraries.

Why the .so file always smaller than the .a file?(the source is identical.)

The link stage (which generates the shared object file) will trim out unused functions etc. and perform other compaction.

The compilation phase (which generates the .a) will not.

What is the difference between a library file and a header file or are they synonymous?

Both are header files.

The first header file provides declarations of some of the functions provided by the C standard library. Therefore, one could say that it is part of the C standard library.

The second header file probably provides declarations of functions that are defined in other parts of your program. Therefore, it is not part of a library.

A library generally provides header files so that you can #include them in your program, so that the compiler has the necessary function declarations in order to call the functions in the library. However, the main part of the library, which consists of the actual function definitions, is not imported by the compiler, but rather by the linker.