2

As we know, linux call ldconfig to load all *.so libraries and then link the applications who use the shared library. However, I am confused how the global variable is working in this case. Since there is only one copy of shared library across all these application, do they share the global variables in the shared library? If yes, then how they synchronize?

Thanks,

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
Alfred
  • 1,709
  • 8
  • 23
  • 38

2 Answers2

5

No it is not shared - the code/text section of the library is shared - the data portion is unique to each process that uses the library

Adrian Cornish
  • 23,227
  • 13
  • 61
  • 77
  • Thanks! BTW, do you have any web links about the dynamic loader, i.e. how does it work. – Alfred Sep 17 '12 at 04:27
  • The `ld.so` dynamic linker is free software (so you could study its source code and improve it), and uses the `mmap` system call to project some `.so` segments into virtual address space of the process. You could `strace` your program to get a feeling of involved system calls. – Basile Starynkevitch Sep 17 '12 at 05:05
  • BTW, `ld.so`, not `ldconfig`, is doing the dynamic linking. `ldconfig` is just configuring that dynamic linker. – Basile Starynkevitch Sep 17 '12 at 05:12
0

As I commented:

  • Levine's book on linkers and loaders is a useful reference.

  • Linux dynamic linker ld.so is free software, part of GNU libc and you can study and improve its source code

  • the dynamic linker is ld.so not ldconfig (which just updated cached information used by ld.so).

  • the ld.so linker is using the mmap(2) system call to project some .so segments into the virtual address space of the process; the "text" segment (for code and read-only constants) uses MAP_SHARED with PROT_READ. The "data" segment (for global or static variables in C or C++) uses MAP_PRIVATE with PROT_WRITE

  • you would learn a lot by strace-ing your program to get a feeling of the involved system calls.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547