Hardware resources

As computer speed and capacity has grown over the years, software has become far more complex. Along with the growth in complexity has come an increase in the amount of code shared between programs. A large percentage of available software now comes in the form of libraries, rather than programs. By having libraries that can be used by many programs, programmers are freed from having to reinvent the wheel, and can utilize their time more efficiently. As the libraries grew, along with the number of programs using them, another problem became apparent: Although programmers were spending less time reinventing the wheel, they were wasting more and more hardware resources by reinstalling the wheel. It became apparent that the growing size and ubiquity of certain common libraries could overwhelm systems in some situations. This is especially true of code used in graphical user interfaces, which is used by many programs, and is inherently big due to sheer amount of tedious work necessary to draw nice-looking graphical windows.

The solution: Shared libraries. Before shared libraries, we had static libraries. A static library is basically an archive of object files (similar to a tar, zip, or cpio archive), from which needed object files are extracted and copied into a program when it is compiled. Static libraries have some advantages, and work fine for many cases, especially when the code in the library is small, and/or used by a small number programs. But when the libraries are big, and widely used, it means there are many copies of the code stored on disk in the programs, and much worse, many copies in memory when those programs are run at the same time. ( Including when multiple users are running the same program. )

Shared libraries solve this problem by separating the library code from the program until runtime. When the program is compiled, only a reference to code from the shared library is inserted, rather than copying the code itself. This makes the program files smaller. On today's computers, this is arguably not much of an issue, since disk space is cheap, and data (such as multimedia files), not programs, tend to use up most of the space.

The greater advantage comes to light when you consider how shared libraries work at run time. When a process is started, the loader (the program that loads all other programs into memory so they can run) checks for shared libraries, and loads them as needed. Once an object from a shared library is loaded into memory, the loader will know about it, and it can be used by other processes, even processes running different programs.

Ports systems maximize the advantages of shared libraries, by encouraging programmers to use the save versions of the same libraries. For example, if a ports system contains a port of the library QT v3.3, most programmers creating ports of programs that use QT will make an effort to utilize the QT 3.3 port. As a result, it's unlikely that multiple versions of the QT code will ever be loaded into memory at once.