Linking against shared objects at compile time

Question

In Windows, many .dlls come with a static .lib counterpart. My understanding is that the .lib counterpart basically contains LoadProcAddress calls so that the programmer doesn't have to do it him/herself. Essentially, a time saver. When I switched to Linux, I was assuming the situation was the same, replacing .dll with .so and .lib with .a, but I have come to a situation that is showing me this is wrong and I can't figure out what is going on:

I am using a library that comes as a .a/.so pair. I was linking against the .a, but when I executed ldd on the binary that was produced, it contained no reference to the corresponding .so file. So then, I tried linking against the .so file and to my surprise, this worked. In addition, the .so file showed up when I executed ldd against the resulting binary.

So, I am really confused as to what is going on. In Windows, I would never think to link against a .dll file. Also, in Windows, if a .dll file was accompanied with a .lib and I linked against the .lib at compile-time, then I would expect to have a dependency on the corresponding .dll at runtime. Both these things are not true in this case.

Yes, I have read the basic tutorials about shared objects in Linux, but everything I read seems to indicate that my initial assumption was correct. By the way, I should mention that I am using Code::Blocks as an IDE, which I know complicates things, but I am 99% sure that when I tell it to link against the .so file, it is not simply swapping out the .a file because the resulting binary is smaller. (Plus the whole business about ldd...)

Anyway, thanks in advance.

Solution 1

I was linking against the .a, but when I executed ldd on the binary that was produced, it contained no reference to the corresponding .so file.

This is expected. When you link statically, the static library's code is integrated into the resulting binary. There are no more references to or dependencies on the static library.

So then, I tried linking against the .so file and to my surprise, this worked.

What do you mean, that the static linking did not work? There's no reason that it shouldn't...

Solution 2

.lib are used in Windows to dynamically link. You don't have them in Linux, you link with .so directly. The .a file is the statically built library, you use it to link statically.

Comments

[Admin]

Right, but in many cases a .lib and .dll are paired together in Windows. The .lib is a small stub library that contains wrapper functions that load the actual functions from the .dll (i.e. LoadProcAddress). I was trying to understand how this works in linux. I think the answer is that when you link against a .so file you are doing something similar, but may be wrong.

[Admin]

no i was surprised that you can link a dynamic library. you cannot link a dll in windows.

[tharibo]

Exactly. In other words, you can consider that the .lib is integrated inside the .so for practical purposes.