Which of the following is NOT an advantage of using shared, dynamically linked…

Answer: Faster program startup is NOT an advantage of using shared, dynamically linked libraries.

Why the other items are advantages of shared libraries:

• Smaller sizes of executable files: Executables do not need to contain duplicate copies of library code; the shared library is stored once on disk and mapped into each process that uses it.

• Lesser overall page fault rate in the system: Multiple processes can share the same physical pages for library code, reducing total memory pressure and the number of page faults compared with each process having a private copy.

• Existing programs need not be re-linked to take advantage of newer versions of libraries: If a new library version maintains compatibility, updating the shared library can provide bug fixes or improvements without rebuilding dependent programs.

Why faster program startup is not an advantage:

• Dynamic loader overhead: The runtime linker/loader must locate and load each dependent library, resolve symbol addresses, and perform relocations before or during execution, which adds to startup time.

• Possible runtime binding costs: Even with lazy binding, the first use of dynamically resolved symbols can incur additional delays.

Takeaway: Shared libraries give smaller executables, memory-sharing benefits, and easier updates without relinking (when ABI-compatible). They do not typically give faster startup; the dynamic linking process often makes startup slower than a comparable statically linked build.