What's the difference between .so, .la and .a library files?

Question

I know an .so file is a kind of dynamic library (lots of threads can share such libraries so there is no need to have more than one copy of it in memory). But what is the difference between .a and .la? Are these all static libraries?

If dynamic libs have big advantages over static ones, why there are still lots of static libraries? When should I try to build code into .so or .a?

[mirror@home ins_openvpn]$ ls lib/openvpn/plugins/ -l
total 96
-rw-r--r-- 1 mirror mirror 22892 Sep  2 23:25 openvpn-plugin-auth-pam.a
-rwxr-xr-x 1 mirror mirror   931 Sep  2 23:25 openvpn-plugin-auth-pam.la
-rwxr-xr-x 1 mirror mirror 23621 Sep  2 23:25 openvpn-plugin-auth-pam.so
-rw-r--r-- 1 mirror mirror 17228 Sep  2 23:25 openvpn-plugin-down-root.a
-rwxr-xr-x 1 mirror mirror   932 Sep  2 23:25 openvpn-plugin-down-root.la
-rwxr-xr-x 1 mirror mirror 18805 Sep  2 23:25 openvpn-plugin-down-root.so

Solution

.so files are dynamic libraries. The suffix stands for "shared object", because all the applications that are linked with the library use the same file, rather than making a copy in the resulting executable.

.a files are static libraries. The suffix stands for "archive", because they're actually just an archive (made with the ar command -- a predecessor of tar that's now just used for making libraries) of the original .o object files.

.la files are text files used by the GNU "libtools" package to describe the files that make up the corresponding library. You can find more information about them in this question: What are libtool's .la file for?

Static and dynamic libraries each have pros and cons.

Static pro: The user always uses the version of the library that you've tested with your application, so there shouldn't be any surprising compatibility problems.

Static con: If a problem is fixed in a library, you need to redistribute your application to take advantage of it. However, unless it's a library that users are likely to update on their own, you'd might need to do this anyway.

Dynamic pro: Your process's memory footprint is smaller, because the memory used for the library is amortized among all the processes using the library.

Dynamic pro: Libraries can be loaded on demand at run time; this is good for plugins, so you don't have to choose the plugins to be used when compiling and installing the software. New plugins can be added on the fly.

Dynamic con: The library might not exist on the system where someone is trying to install the application, or they might have a version that's not compatible with the application. To mitigate this, the application package might need to include a copy of the library, so it can install it if necessary. This is also often mitigated by package managers, which can download and install any necessary dependencies.

Dynamic con: Link-Time Optimization is generally not possible, so there could possibly be efficiency implications in high-performance applications. See the Wikipedia discussion of WPO and LTO.

Dynamic libraries are especially useful for system libraries, like libc. These libraries often need to include code that's dependent on the specific OS and version, because kernel interfaces have changed. If you link a program with a static system library, it will only run on the version of the OS that this library version was written for. But if you use a dynamic library, it will automatically pick up the library that's installed on the system you run on.

Comments

[Pacerier]

Also see autotools.io/libtool/lafiles.html

[Pacerier]

@Barmar, So you are saying that the advantages of static libraries outweigh the advantages of dynamic libraries?

[Barmar]

@Pacerier I don't know where you got that from.

[Pacerier]

@Barmar, How would you weigh static library against dynamic libraries and which will you select as winner (if there can only be one winner)?

[Barmar]

That's a meaningless question. The weight of the pros and cons depends on the circumstances, there's no universal answer. It seems like you have an agenda, and you're trying to bait me.

[Pacerier]

@Barmar, Nop I'm innocent. Just a curious-er.

[Sam]

Another factor is licensing - LGPL requires dynamic linking in a commercial context, i.e. where you don't want to distribute your source.

[janjust]

Since you linked to another question whose answer to the question what are .la files was accepted as: "It is a textual file that includes a description of the library." Why do you say that .la files are static libraries. Are they? They are just descriptions. They don't contain any code and data sections.

[DavidS]

@Sam The LGPL license is not a factor in this discussion.

[Prathu Baronia]

Can someone mention the cons of Dynamic libraries, if there are any?

[Barmar]

@PrathuBaronia I added a con paragraph.

[Keith M]

@DavidS I think LGPL was just meant to give an example of a library with restricted usage. Nothing wrong with using examples to demonstrate a point.

[knia]

I think this answer should mention the difference in performance, which can be a big reason for using static libraries.

[Barmar]

@A.Hennink I wasn't aware that there's a significant performance difference. Maybe just during program startup, when it's finding and linking the .so.

[knia]

Isn't there a performance hit if a dynamic library cannot support the interprocedural optimization across the library call? This is also discussed on Wikipedia. I find that calling Intel's wrappers for MKL BLAS many times (e.g., 1e7) for small matrix multiplications (e.g., 20x20) is faster (e.g., 10%) when linking to the static libraries. This is a normal use case for finite element codes, though I think not many people on SO are into high-performance computing.

[Barmar]

@A.Hennink "Static linking does naturally lend to the concept of LTO, but it only works with library archives that contain IR objects as opposed to machine-code only object files." I'm not sure if that applies to .a libraries.

[knia]

You can compile IR objects, and bundle them in a .a library (which I've done with Fortran, never with C/C++, but that should not matter). I'm not sure that's possible with a dynamic library, because the whole point is that the compiler needs to 'see' the external library code before runtime.

[Barmar]

OK, I've added a paragraph about that.