linking, loading, and virtual memory

Question

I know these questions have been asked before - but I still can't reconcile everything together into an overall picture.

1. static vs dynamic library
   • static libraries have their code copied and linked into the resulting executable
   • static libraries have only copy and link the required modules into the executable, not the entire library implementation
   • static libraries don't need to be compiled as PIC as they are apart of the resulting executable
   • dynamic libraries copy and link in stubs that describe how to load/link (?) the function implementation at runtime
   • dynamic libraries can be PIC or relocatable
   • why are there separate static and dynamic libraries? All of the above seems to be be the job of the static or dynamic linker. Why do I need 2 libraries that implement scanf?
   • (bonus #1) what does a shared library refer to? I've heard it being used as (1) the overall umbrella term, synonymous to library, (2) directly to a dynamic library, (3) using virtual memory to map the same physical memory of a library to multiple address spaces. Can you do this only with dynamic libraries? (4) having different versions of the same dynamic library in memory.
   • (bonus #2) are the standard libraries (libc, libc++, stdlibc++, ..) linked dynamically or statically by default? I never need to dlopen()..
2. static vs dynamic linking
   • how is this any different than static vs dynamic libraries? I don't understand why there isn't just 1 library, and we use either a static or dynamic linker (other than the PIC issue). Instead of talking about static vs dynamic libraries, should we instead be discussing the more general static s dynamic linking?
   • is symbol resolution still performed at compile-time for both?
3. static vs dynamic loading
   • Static loading means copying the full executable into MM before executing it
   • Dynamic loading means that only the executable header copied into MM before executing, additional functionality is loaded into MM when requested. How is this any different from paging?
   • If the executable is dynamically linked, why would it not be dynamically loaded?
   • both static loading and dynamic loading may or may not perform relocation

I know there are a lot of things I'm confused about here - and I'm not necessary looking for someone to address each issue. I'm hoping by listing out everything that is confusing me, that someone that understands this will see where a lapse in my understanding is at a broad level, and be able to paint a larger picture about how these things cooperate together..

Answer 1

why 2 types of lib loading

• dynamic saves space (you dont have hundreds of copies of the same code in all binaries using foo.lib
• dynamic allows foo.lib vendor can ship a new version of the library and existing code takes advantage of it
• static makes dependency management easier - in theory a binary can be one file

What is 'shared library'

• unix name for dynamic library. Windows calls it DLL

Are standard libraries static or dynamic

• depends on platform. On some you can choose on others its chosen for you. For example on windwos there are compiler switchs to say if you want static or dynamic runtimes. Not dont confuse dynamic library usage with dlopen - see later

'why we talk about 2 different types of library'

Typically a static library is in a different format from a dynamic one. Typically a static library is input to the linker just like any other compile unit. A dynamic library is typically output by the linker. They are used differently even though they both deliver the same chunk of code to your app

Symbol resolution is finalized at load time for a DLL

Full dynamic loading. This is the realm of dlopen. This is where you want to call entry points in a library that might not have even existing when you compiled. Use cases:

• plugins that conform to a well known interface but there can be many implementations (PAM and NSS are good examples). The app chooses to load one or more implementations from specified files at run time

• an app needs to load a library and call an arbitrary function. Imagine how , for example , how a scripting language can load and call an arbitrary method

To use a .so on unix you dont need to use dlopen. You can have it loaded for you (Same on windows). To really dynamically load a shared lib / dll you need dlopen or LoadLibrary

Answer 2

Note that statically linked libraries load faster, since there is less disk searching for all the runtime library files. If the libraries are small, and very unusual, probably better to link statically. If there are serious version dependencies / functional differences like MFC, the DLLs need different names.