Question

I have read about static and dynamic libraries.

My question is little specific.

dlopen dlclose :

Benifit of dlopen is  we can start the EXE with out
loading the necessary libraries at the begining. Only when we
need we will load the libratries and unload it from the memory.

This is behaviour of dynamic linking libaries.

My question is if i link the library libUtlities

ld -o EXE main.o -lUtilities 

When I run the EXE, libUtlities will be loaded to the memory before
I first use there functionalities

which i observed in dbx (Solaris debugger)
But will not contribute to the size of the EXE.

1.So is it a static linking or dynamic linking. ?

Answer 1

Unfortunately, the words “static” and “dynamic” are way too overused, especially in C and C++. So, I prefer the following terminology:

• Link-time linking, a.k.a “static linking”: All symbols are resolved at link time from static libraries. The result is a monolithic, statically linked executable with no load-time dependencies.

• Load-time linking: This is the standard practice on modern platforms, unresolved symbols are looked up in shared libraries (Unix) or the unfortunately named dynamic link libraries (DLLS) on Windows and only references are recorded at link time, the actual resolution of the symbols and code loading happens at load time.

  This results in a “dynamically linked” executable which must be loaded with a loader (e.g. ld.so on Linux). Loading is part of the OS and usually transparent to the user, though it’s open to inspection (e.g. with ldd on Linux). All shared libraries must be available at load time, or the program will not launch.

• Run-time linking, a.k.a. “dynamic linking”: There are no unresolved symbols; rather, the runtime dynamically decides to look up symbols in a shared/dynamic library using dlopen() or LoadLibrary(). Failure to find symbols is a handlable runtime condition that is not an error. This technique is used commonly for plug-in architecture, and on Windows for code injection.

Note however that there is a fundamental technical difference between Linux’s shared objects and Windows’s DLLs, they’re not just the same thing with a different name. Both can however be used both for load-time and run-time linking.