System designers have a responsibility to help the rest of the system's community by providing a useable system. I'll make the following observations regarding shared libraries as if you and I were debating putting shared libraries into a system. I have worked both sides of this issue, so I have an experienced opinion, not just apriori idea of good system hygiene.
First, let me deal with your two `advantages.' > #1 Maintenance - If you have 50 programs that depend on one library > and you have a fix for the library how many things do you want to > "remember to build"? (though people are throwing up straw man > arguments for this too. I suspect the worst case scenario is not > always the common case though.) This has an ugly other side. If I have 50 programs that depend on one library and fix a bug in the library, I now have 50 live programs in production that haven't been tested. I don't know if my change has broken something else and won't know until I re-test all 50 programs. I now have to do all that testing at once. With static libraries I have the luxury of going thru the 50 programs one at a time and relinking them with the new library or reverting to an old library if there's a problem. > > #2 Supposed physical memory savings - libSystem on Mac OS X only > exists in memory 1 time for all the programs that use it... sorta. > Read Only pages are shared, writable pages are COW and yes, this adds > a good deal of complexity to the VM of the OS to have this. Before X windows, 10% of programs were from the library. With X windows that number ballooned to 90%, so there is an apparent (see below) space savings with X windows. This is because when to touch anything you get everything. That, I would argue, is bad design. (I added shared library to a custom embedded Unix I did 15 years ago because the application was also mis-designed.) The X library is really a sub-system that should be somewhere other than the user's program. Also on the down side, shared libraries make it hard to distrubute binaries without also sending out the library. The binary, or even the files in the same directory, are no longer all that is required to run the program. You also have to have the correct version of the library. Since you get different binaries that need different versions of the library, you now wind up with three or six or more slight variations of the same library, all get loaded into core. Now, where's my space saving? Remove one and now you have a bunch of programs that don't work, but you don't know it yet. To load a binary that is linked to a library takes longer to load. I have seen code sharing done right, such as Oberon, but every version of shared libraries in Unix I've seen cost more than they were worth. Including my own. Hope the above arguments at least seem rational. They are off the top of my head. I'm sure others on 9fans have other, better data points that do the engineering calculation on the cost/benefits of shared libraries. bc
