Statically link libraries

Shared libraries take time to load. When an application is linked to a shared object, the process loader will first check whether that shared object is already loaded. If it isn't, the loader must load the object out of permanent storage first (IFS, EFS, or elsewhere). The process of loading the various ELF sections from the file can take time. Even if the shared object is already in memory, the application must have fixups applied. The dynamic linker must look up the symbol names to get the appropriate addresses.

For a large shared object, it can be significantly quicker to statically link the application with the biggest libraries. That way, you pay for the linker lookup penalties at compile time rather than at runtime. Of course, statically linking an executable will consume more flash memory if multiple applications call from that library. Also, this practice may introduce version incompatibilities between applications if the shared library changes and you don't rebuild everything it's linked against. But for some systems, the performance benefits will outweigh the drawbacks.