Mark Duckworth wrote:
On Mon, 2005-07-18 at 17:47 -0500, Evan Langlois wrote:Static libs don't require a mess of excess files outside the program itself that need to managed with package managers and special file system layouts and version control systems. They also load faster in spite of the larger file size since only the required functions from each library are loaded instead of loading an entire shared library and them doing the linking at run-time. The snappy load time of apps gets slower and slower as you add more and more dynamic libs to the system.I can't *believe* we have someone arguing for static libs! Look, we have nobody going around rebuilding packages when mintlib gets bugfixes so until we have such a volunteer, dynamic shared libs gets my vote.
Dynamic shared libs are no help if the newer library changes an API incompatibly with the old one.
Another interesting approach would be to keep enough symbol table info in statically linked apps to allow them to be relinked. That is, run a linker command
relink foo.app -lnewlibwhich replaces all the symbols in foo.app that appear in newlib with the version from newlib. So you can keep your snappy static library load times, but still take advantage of bugfixed libraries over the course of time. The IBM linker does this on most of their operating systems (AIX, OS/390, z/OS)... It requires an object format that records both the address and the size of every symbol. They really have a lot of good ideas in their dev tools, better than what SVR4/Sun/Linux have to offer.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/