Most people will tell you that you should use dynamic libraries instead of static libraries whenever possible. Ok, but what\'s the difference? Glad you asked. The difference between static and dynamic libraries can be viewed as how you get to work. You can drive your car or you can take a train. Driving your own car is kinda like a static library. Taking the train is kinda like a shared library. When you drive your car all you need is the car. When you take the train there is usually more than one train car by itself. Usually there\'s a locomotive, and then some passenger cars, and maybe a caboose to boot. As long as all the cars are working in harmony you continue to get to work. If any of the cars has a problem your chances of getting to work diminish. When you compile a program with static libraries statically linked libraries are linked into the final executable by the linker. This increases the size of the executable. Likewise when a library needs to be updated you\'ll need to compile the new library and then recompile the application to take advantage of the new library. Ok, so why do we have static libraries then? Well if you\'re booting your system into maintenance mode static libraries can be beneficial. In our example above if any of the train cars are missing then the train doesn\'t move. With dynamic libraries if all the libraries aren\'t present then the application doesn\'t run. So if you have a partition that holds your libraries and it becomes unavailable then so does the application. If an application has static libraries then the libraries are always present so there is nothing to prevent the application from working. On a Solaris system commands that you may need to run in the event that some partitions may not be present are stored under /sbin. sbin is short for static binaries. If a partition is unavailable these apps will still work. It\'s like driving your car; you don\'t have any other dependencies. On Solaris 10 please be sure that your /lib directory is on the same partition as your /sbin directory, otherwise you may have problems at the worst possible moment. There was a significant change to the Solaris threading module that was introduced in Solaris 10. Because of this change the binaries in /sbin are now compiled using shared libraries whereas before they were compiled using static libraries. The book, \"Solaris Internals: Solaris 10 and OpenSolaris Kernel Architecture, 2nd Edition,\" describes the changes to the threading model and how it impacted other parts of the operating system. Ok, maybe static libraries don\'t sound too bad after all, but what are dynamic libraries? Dynamic libraries are libraries that have the library name embedded into the executable but the library itself is not compiled into the binary file. This makes upgrading libraries easier. You can upgrade the library and the application will still work barring any unforeseen changes to the library itself. If the name of the library changes you can just create a symbolic link to the old library name and your back in business. Also, since the library is not compiled into the executable the executables tend to be smaller. If you have a lot of programs that utilize the same library you might be able to save considerable disk space. If you have a lot of programs that utilize the same library you only need to upgrade the library and then all the programs that use it go on as if nothing has changed. Since the libraries are shared the memory footprint goes down as well. There is a third type of libraries that are used by programs. These are called dynamically loaded libraries. These libraries are built as normal shared or statically linked libraries. The difference is that they are not loaded at program startup, instead you would use the dlsym() and dlopen() application programming interface to activate the library. This is how you get web browser plugin\'s, modules (Apache), or just in time compilers to work. When you are done using the library, you would call dlclose() to remove the library from memory. Errors are handled via the dlerror() application programming interface.