If both of them contain compiled code, why can\'t we load the \"static\" files at runtime and why can\'t we link with the dynamic libraries at compile time? Why is there a need
A static library is just a tarball1 of .o or
.obj` files. When an executable is linked the referenced modules (and the ones that they reference, and then the ones that they reference, and then ... etc) are copied out of the static lib and tacked onto the end of the main program. This whole thing is paged into memory as a single OS "object".
A dynamic library just takes all the elements of the static library, links them together (resolving intramural relationships) and then maps the whole thing into memory. (Demand paging may make a partial memory presence attainable.) A certain amount of fiddling is necessary when launching dynamic programs in order to hook up the main program (which will be "statically" linked within its own modules) to the library that is shared system-wide. Sometimes this fiddling is delayed per-linkage-element until a given call is made. In a very broad, overly-conceptual sweep one could categorize static linking as eager loading and dynamic as lazy loading.
There are pluses and minuses with static libraries.
✚ No DLL hell (aka dependency hell)
✚ Much smaller memory footprint for small run-time process mixtures
− Much larger memory footprint for large run-time process mixtures of disparate programs
− Can't share any library code memory between processes except when they are running the same program
− A large set of programs (like Linux/Windows/Mac footprints) take up a lot of space as printf et al are duplicated over and over in each image
− It's difficult if not impossible to fix security bugs originating in libraries
− It's difficult if not impossible to update a library alone
✚ It's difficult if not impossible to update a library alone and break your program
1. Actually, they aren't in tar(1) format, but it's related.