2

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. ?

Enlico
  • 23,259
  • 6
  • 48
  • 102
vrbilgi
  • 5,703
  • 12
  • 44
  • 60
  • 4
    The first quote is rather bogus. If someone is using dynamic loading for this purpose, they're just making their code unnecessarily ugly and complex. The **only** legitimate purpose of dynamic loading is to make a program that supports loading *new code* that was written *after the program itself was linked/distributed* or *by a third party* into the program. – R.. GitHub STOP HELPING ICE Aug 27 '11 at 14:51

2 Answers2

11

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.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • You seem to be mixing shared libraries and statically/dynamically linked libraries. There can be statically linked shared libraries. Can you please explain why that difference isn't important here? – Johannes Schaub - litb Aug 27 '11 at 13:40
  • @Johannes: Where exactly am I mixing those up? The definitions apply recursively, I suppose, so the shared library itself can be either monolithic (statically linkded) or have load-time dependencies on its own, but that shouldn't contradict anything I said, non? – Kerrek SB Aug 27 '11 at 13:43
  • One could link a program `foo` with `libc`, such that all names in `foo` are linked to statically known addresses of functions in `libc`, with a fixed load address of `libc`. That's static linking (and tricks like `LD_PRELOAD` are not possible) to a shared library (`libc`). But `foo` would still have a load-time dependency (if we remove `libc` from the disk, things fail at runtime because the code cannot be loaded from `libc`). You said "Link-time linking, ... the result is a monolithic, statically linked executable with no load-time dependencies.". Or am I missing something? – Johannes Schaub - litb Aug 27 '11 at 13:51
  • @Johannes: Ah, indeed I said that, and I wasn't aware that you could do this. How would you do this? Is this a typical situation? I'm happy to amend that paragraph! – Kerrek SB Aug 27 '11 at 13:53
  • @KerrekSB, as regards the last bullet, am I correct to understand that if my program, say `main.cpp`, uses `dlopen` to load a library, that means that I compile-and-link my program without making any mention of the shared/dynamic library, e.g. I can just `g++ main.cpp -o main`? (Clearly I expect that I still need to `#include` the appropriate library headers in `main.cpp`, in order to be able to cast the `void*`s coming from `dlsym` to the appropriate types.) – Enlico Oct 09 '22 at 09:11
3

It is dynamic linking. It has nothing to do with dlopen dlclose. By dlopen you are manually opening dynamic library and calling functions exported from it. By dynamic linking all this job is done by linker. Static linking is linking against static library (.a file). By static linking the code from library is linked into your exe increasing it's size.

ks1322
  • 33,961
  • 14
  • 109
  • 164
  • @ks thanks for replying: so except dlopen dlclose case, when we start the EXE all the dependency lib will occupy the memory. – vrbilgi Aug 27 '11 at 13:30
  • All dynamically linked libraries (those which reported by `ldd`) will be loaded into memory together with EXE. Statically linked libs are already inside EXE. Libs opened by `dlopen` are loaded into mem directly after `dlopen` and unloaded directly after `dlclose`. – ks1322 Aug 27 '11 at 14:41