static shared lib vs dynamically shared lib

[ITchimp]

Referring the linker and loaders by John Levine, I understand linux support static and dynamic libs...does it really mean static shared lib and dynamically shared libs? does the static version of lib has a jump table in front of it link what Levine described, how can I find out more about this?

[Octocontrabass]

Static shared libraries are obsolete. You won't find them in any modern OS.

Static shared libraries are not the same thing as static libraries.

[nullplan]

Static shared libraries are obsolete. You won't find them in any modern OS.

Are you guys talking about non-relocatable shared libs? If so, then seconded. Those things are a trainwreck.

[ITchimp]

why is static shared lib obsolete?

If static shared lib is obsolete, does that mean that static non-shared libs will have printf routine copied into the binary executable for it to run standalone...

non-relocatable shared lib?

What is it? I thought the concept of static shared lib is a jump table at the front of lib routine so the actual address is decoupled

[iansjack]

Yes, the functions in a static library that a program uses are copied into the executable. This makes the program faster and more portable. But the program is larger, uses more memory (in general) and needs to be recompiled to take advantage of improvements to the library.

I can’t see any advantage that a static shared library would have over a dynamic one.

[nullplan]

If static shared lib is obsolete, does that mean that static non-shared libs will have printf routine copied into the binary executable for it to run standalone...

A static library is an archive of object files, and the linker adds all object files to the link that are referenced, directly or indirectly. printf() is a good example of a function that does not lend itself to static linking, since you get all the code, including the complicated hex-float printing logic, even if all you do at run-time is to only print a single decimal integer.

However, notice that with static libraries, you only get what you reference. A simple hello-world program doesn't get a copy of system() in the address space. This is a benefit if the program has a security hole: A hacker planting shellcode cannot jump to system() if the function is not in address space.

What is it? I thought the concept of static shared lib is a jump table at the front of lib routine so the actual address is decoupled

I still don't know what a "static shared lib" is, and Google is not helping me. But what you describe sounds like a shared lib with DT_TEXTREL in the dynamic segment. And those are horrible for two reasons:

One is memory usage. Writing into the code segment of a mapped file copies the mapping. This basically ensures non-sharing of code pages, which basically negates the entire point of shared libraries in the first place.

The other is more practical: The dynamic linker needs to handle more relocation types with DT_TEXTREL libraries, many of which completely arch-specific. This makes the code more complicated, and thus more error-prone, harder to maintain, harder to understand, harder to test... nothing good comes of it. With dynamic linking, you only need to handle a handful of types, and the themes repeat on different architectures.

[Octocontrabass]

I still don't know what a "static shared lib" is, and Google is not helping me.

Chapter 9 of the aforementioned Linkers and Loaders book describes them in some detail. Google should be able to find it for you.

But what you describe sounds like a shared lib with DT_TEXTREL in the dynamic segment.

No, it's worse than that: they have no dynamic segment. They're not relocatable at all. The jump table is there to make it possible to update the library without changing the addresses of the symbols it exports, since any addresses that change require re-linking every program that relies on the library.

[eekee]

Non-relocatable code reminds me of the long runs of zeros I saw when hex-dumping Windows 3.1 libraries. I also have a faint memory of being told, in the 80s or 90s, that linkers left room between items in case of future changes. In that era of tight memory contraints, memory had to be wasted like this! A jump table removes the memory issue but slows down every call. And many CPUs have no need of it. I don't quite understand why it was needed on the 286. It's certainly unnecessary on a 486. Architectures which really can't support position-independent code are likely to be MMU-less and can thus efficiently run microkernel-style services instead of libraries. Or, if you're willing to slow down program loading and maybe bloat disk usage with symbols, your loader could fully relink every library and executable at load time, making all code position-independent without hardware support. (In the past, linkers themselves were commonly called loaders.)