When creating a windows static library, we simply create a .lib file which should be included in the linker path.

When creating a windows shared library, along with the .dll, we also a generate a .lib file. This lib file contains the signatures of the API exposed by the library.

There are two ways to use this library

  1. Either we can directly refer the library API in our project and add the path to .lib file in the linker properties. Some people call it as statically linked dynamic library
  2. Or we can explicitly load the dynamic library during runtime. In this case we need not specify the lib file path for linker. Call it dynamically linked dynamic library.

My question is do we have something similar for shared libraries on Linux also? or just the static library (.a) and shared library (.so)?

I know how to include a static library on linux using gcc -l option. Can we use the same option for including a dynamic library (.so) also?

1 Answer 1


I can't say I understand what a "statically linked dynamic library", nor do I know anything about signatures contained in libraries (sounds interesting though: does this mean the linker is able to check for type mismatches in arguments and return types at link time? ELF definitely does not have such a feature.) so this answer will not be from a comparative point of view. Also, as your question is very broad, the answer will be superficial in detail.

Yes, you can create either a static library (.a) or a shared library (.so). When the linker looks for libraries requested with -l, it will prefer the shared library if both exist, unless overridden with an option like -static.

When building a library from source code, one only needs to build it as a static library (.a) or as a shared library (.so), not both. Still, quite a few packages' build scripts are set up to build both versions (which requires compiling twice, once with position independent code and once without) in order to give consumers of the library the choice of which one to link with.

The necessary pieces of a static library are totally incorporated into the binary that is built. There is no need to have the .a file available at run time. In contrast, a shared library that was linked to a binary has to be available at run time, although the run-time dynamic linker will typically search for it under a modified name, its "soname" (usually libsomething.so at link time and libsomething.so.<integer> at run time), which is a feature that allows multiple different versions of a library with slightly different APIs to be installed in the system at the same time.

In your question you mention also explicitly loading dynamic libraries at run time. This is often done for modular applications or applications with plugins. In this case, the library in question (often called a "module" or "plugin") is not linked with the application at all and the build-time linker knows nothing of it. Instead, the application developer must write code to call the run-time dynamic linker and ask it to open a library by filename or full pathname. Sometimes the names of the modules to open are listed in the application's configuration file, or there is some other piece of application logic that decides which modules are or aren't needed.

  • Thanks for the elaborate answer. If you are using a function from a dll in your program, the linker has to resolve the symbol. So it refers to the .lib file corresponding to the dll to check the signature/type. Commented Nov 19, 2014 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .