动态链接 - Linux 与。 Windows

Question

Under Windows, when I compile C/C++ code in a DLL project in MSVC I am getting 2 files:

1. MyDll.dll
2. MyDll.lib

where as far as I understand MyDll.lib contains some kind of pointers table indicating functions locations in the dll. When using this dll, say in an exe file, MyDll.lib is embedded into the exe file during linkage so in runtime it "knows" where the functions are located in MyDll.dll and can use them.

But if I compile the same code under Linux I am getting only one file MySo.so without MySo.a (the equivalent to lib file in Linux) so how does an executable file under Linux knows where the functions are located in MySo.so if nothing is embedded into it during linking?

Answer 1

The MSVC linker can link together object files (.obj) and object libraries (.lib) to produce an.EXE or a.DLL.

To link with a DLL, the process in MSVC is to use a so-called import library (.LIB) that acts as a glue between the C function names and the DLL's export table (in a DLL a function can be exported by name or by ordinal - the latter was often used for undocumented APIs).

However, in most cases the DLL export table has all the function names and thus the import library (.LIB) contains largely redundant information (" import function ABC -> exported function ABC ", etc).
It is even possible to generate a.LIB from an existing.DLL.

Linkers on other platforms don't have this "feature" and can link with dynamic libraries directly.

Answer 2

On Linux, the linker (not the dynamic linker) searches through the shared libraries specified at link time and creates references to them inside the executable. When the dynamic linker loads these executables it loads the shared libraries they require into memory and resolves the symbols, which allows the binaries to be run.

MySo.a , if created, would actually include the symbols to be linked directly into the binary instead of the "symbol lookup tables" used on Windows.

rustyx's answer explains the process on Windows more thoroughly than I can; it's been a long time since I've used Windows.

Answer 3

The difference you are seeing is more of an implementation detail - under the hood both Linux and Windows work similarly - you code calls a stub function which is statically linked in your executable and this stub then loads DLL/shlib if necessary (in case of delayed loading , otherwise library is loaded when program starts) and (on first call) resolves symbol via GetProcAddress / dlsym .

The only difference is that on Linux the these stub functions (which are called PLT stubs) are generated dynamically when you link your app with dynamic library (library contains enough information to generate them), whereas on Windows they are instead generated when DLL itself is created, in a separate .lib file.

The two approaches are so similar that it's actually possible to mimic Windows import libraries on Linux (see Implib.so project).

Answer 4

On Linux, you pass MySo.so to the linker and it is able to extract only what is needed for the link phase, putting in a reference that MySo.so is needed at run time.

Answer 5

.dll or .so are shared libs (linked in runtime), while .a and .lib is a static library (linked in compile time). This is no difference between Windows and Linux.

The difference is, how are they handled. Note: the difference is only in the customs, how are they used. It wouldn't be too hard to make Linux builds on the Windows way and vice versa, except that practically no one does this.

If we use a dll, or we call a function even from our own binary, there is a simple and clear way. For example, in C, we see that:

int example(int x) {
  ...do_something...
}

int ret = example(42);

However, on the asm level, there could be many differences. For example, on x86, a call opcode is executed, and the 42 is given on the stack. Or in some registers. Or anywhere. No one knows that before writing the dll , how it will be used. Or how the projects will want to use it, possible written with a compiler (or in a language.) which doesn't even exist now (or is it unknown for the developers of the dll).

For example, by default, both C and Pascal puts the arguments (and gets the return values) from the stack - but they are doing it in different order . You can also exchange arguments between your functions in the registers by some - compiler-dependent - optimization.

As you see correctly, the Windows custom is that building a dll, we also create a minimal .a / .lib with it. This minimal static library is only a wrapper, the symbols (functions) of that dll are reached through it. This makes the required asm-level calling conversions.

Its advantage is the compatibility. Its disadvantage is that if you have only a.dll, you can have a hard time to figure out, how its functions want to be called. This makes the usage of dlls a hacking task, if the developer of the dll does not give you the .a . Thus, it serves mainly closedness purposes, for example so is it easier to get extra cash for the SDKs.

Its another disadvantage is than even if you use a dynamical library, you need to compile this little wrapper statically.

In Linux, the binary interface of the dlls is standard and follows the C convention. Thus, no .a is required and there is binary compatibility between the shared libs, in exchange we don't have the advantages of the microsoft custom.