Shared Libraries vs DLLs [Answered]

[TyrelHaveman]

Greetings,

I'm at a point where I'm considering whether shared libraries or DLLs would be best to use in my operating system. I know a lot about how DLLs work and how a loader would work that uses them, but I don't know anything about shared libraries, really, other than they seem to be used in Linux at least.

If you can point me to resources to answer my questions or just answer them here, that'd be great.

Assuming I know what a DLL is, can you explain how a shared library differs?

Is there an advantage of using shared libraries over DLLs?

If I were to use DLLs, I assume PE would be pretty much be the executable format of choice? What about shared libraries... ELF?

Your assistance would be greatly appreciated.

Thanks,
Tyrel

[cyr1x]

Aren't DLL's shared libraries ? I think they are.

[TyrelHaveman]

Aren't DLL's shared libraries ? I think they are.

I thought I read something on this forum somewhere that said something like "shared libraries and DLLs are different" but then didn't go on to explain why. That's why I was asking. Perhaps whoever said that was wrong, in which case you can disregard my questions.

[TyrelHaveman]

Aren't DLL's shared libraries ? I think they are.

I thought I read something on this forum somewhere that said something like "shared libraries and DLLs are different" but then didn't go on to explain why. That's why I was asking. Perhaps whoever said that was wrong, in which case you can disregard my questions.

Here's something from the Intel 64 / IA-32 manual volume 2B page 4-370 which also leads me to believe that they may be different things:

The fast system call “stubâ€

[cyr1x]

"Shared library" is just a hyperonym for DLL's or shared objects (Linux)

[loki]

Dlls are also shared libraries in Portable Executable Format.
On the other hand shared libraries on linux (those with .so extension) are in ELF format. One of the main design differences is that the ELF objects wont tell you which libraries it wants to import, you just have symbol names. So when a function "foo" is exported from lib1.so, there must not be another shared library exporting "foo". And for every symbol you have to search all global shared libraries. With PE files you have library and symbol list, so you know which library to import.

[TyrelHaveman]

Dlls are also shared libraries in Portable Executable Format.
On the other hand shared libraries on linux (those with .so extension) are in ELF format. One of the main design differences is that the ELF objects wont tell you which libraries it wants to import, you just have symbol names. So when a function "foo" is exported from lib1.so, there must not be another shared library exporting "foo". And for every symbol you have to search all global shared libraries. With PE files you have library and symbol list, so you know which library to import.

Thanks loki. It sounds like I was asking the wrong question, but you gave me the answer I wanted to the question I didn't know I was asking. Or something.

I was leading toward using PE because it seems (in my limited knowledge) to be more versatile than ELF. Your description of the differences between ELF shared objects and PE DLLs makes me lean more.

Thanks again.

[Solar]

Not having toyed with ELF / dynamic linking myself yet aside from admin'ing my Linux box, but...

DOne of the main design differences is that the ELF objects wont tell you which libraries it wants to import, you just have symbol names.

...as far as I know, the ELF binary does state which library it is to be linked against (DT_SONAME - "This element holds the string table offset of a null-terminated string, giving the name of the shared object." (System V ABI). That is the whole point behind the .so naming / symbolic link sheme and files like /etc/ld.so.cache.

So when a function "foo" is exported from lib1.so, there must not be another shared library exporting "foo".

Actually you can have different versions of the same .so on your system, which would not be possible if your claim were true.

And for every symbol you have to search all global shared libraries.

That would be exceedingly stupid, now would it, opening every library on disk to search it's symbol list?

[JamesM]

I've toyed with ELF/ dyn linking a little - Just linking dynamically against symbols exported from my kernel.

ELF does specify the name of imported libraries.

When a library is loaded (by ld.so or whatever) the loader sets a custom-defined value at a specific point in memory (the Global Offset Table). When a symbol from that library is referenced, your link function is called with both the symbol number and that custom value as parameters. That way multiple identical symbols can be exported from multiple libraries (good luck getting that to work - it'll work in principle but the static linker will probably complain about duplicate symbols and die first).

OP: In summary: DLLs are for PE executables, SOs are for ELF executables. Functionally there is no difference.

[TyrelHaveman]

In summary: DLLs are for PE executables, SOs are for ELF executables. Functionally there is no difference.

Thanks JamesM, and others, for the clarification.

[Sutoka]

Actually from complaints I've read about how ELF works it does two things:

It has a list of libraries it wants to link against, and it has a list of symbols, BUT it is possible that the following scenario could occur:

You link against two libraries:
libImages.so.2
libPNG.so.1

BUT, libImages.so.2 links against libPNG.so.2, which would (or maybe just could if the planets align the wrong way? not sure) cause the linker to link symbols that were supposed to link against libPNG.so.1's in your main program, if they also exist in libPNG.so.2, and libPNG.so.2 is linked before libPNG.so.1, the .2 one will be linked against by mistake.

It's possible I could be remembering it wrong and that what would occur would be libImage.so.2 using libPNG.so.1's symbols by mistake, but this is the situation (as best I could remember it off the top of my head) that I read about before.

Now how that compares to DLLs, I don't know.

[JamesM]

When a library is loaded (by ld.so or whatever) the loader sets a custom-defined value at a specific point in memory (the Global Offset Table). When a symbol from that library is referenced, your link function is called with both the symbol number and that custom value as parameters.

Given this mechanism I cannot see how that scenario could arise. it seems to be the fault of the static linker...?

[Sutoka]

After a bit of googling I found the site where I read about this problem with ELF. It's on a list of problems with Linux made by the AutoPackage people. After the description of the problem they list a few things that could be done to reduce the problem/possibly fix it.

[Colonel Kernel]

Functionally there is no difference.

Nope, there is a huge difference. When you write code in C or C++ and compile it into a DLL on Windows, the only symbols that are exported from the DLL are those you explicitly mark with __declspec(dllexport) or those that you put in a .def file (I think that's the old way of doing it). On *nix platforms, when compiling your code into a shared library, all symbols with external linkage will be visible when your shared library is loaded, and could potentially conflict with symbols of the same name in other libraries loaded by the executable, or in the executable itself.

This difference has caused massive headaches for naïve Windows developers trying to port their libraries to *nix.

[JamesM]

so use --retain-symbols-file ...?

You're just describing the default, "out of the box" setup.