lazy loading of a shared library 4634

I suspect that is an artifact of the way it is run or linked in ... probably the C runtime envirnment (crt0.o, or whatever) is responsible via calling the init() routine of each shared library it knows about from a certain section of the ELF object. But as a matter of general principle (other) symbols are individually and by default only resolved AS they are encountered in the program, not BEFORE they are encountered.

I think you want to make precise what you mean by "loaded", and what you mean by "initialization" too. I suspect you will find that what linux does is look at the symbol tables of the libraries at the time you indicate them, but not "load" them in a more profound sense. I see for example, wrt dynamic linking against libc:

fstat(3, {stmode=SIFREG0755, stsize=888096, ...}) = 0 read(3, "-177ELF-1-1-1-0-0-0-0-0-0-0-0-0-3-0-3-0-1-0-0-0-244-213"..., 4096) = 4096 oldmmap(NULL, 902428, PROTREADPROTEXEC, MAPPRIVATE, 3, 0) = 0x40033000 mprotect(0x40108000, 29980, PROTNONE) = 0 oldmmap(0x40108000, 16384, PROTREADPROTWRITE, MAPPRIVATEMAPFIXED, 3, 0xd4000) = 0x40108000 oldmmap(0x4010c000, 13596, PROTREADPROTWRITE, MAPPRIVATEMAPFIXEDMAPANONYMOUS, -1, 0) = 0x4010c000 close(3)

which strikes me as being reading the symbol table, not "loading" it. Note that only 4KB is read, and only 16KB is mmapped (for reading?). That is certainly not the whole library. I don't think it is the set of routines in it that I used either, since the single segment mmpapped is contiguous, and come from what looks like the end of the library (0xd4000 is umm, about 800K, and my libc.so is 888K in size)... it's the symbol table.

I think you have perfection then. I believe that is what happens by default.

Peter