Disk savings isn't so important with shared libs (unless your / is already tight).
VM savings is a bit more important, IMO (much better sharing with shared libs). Better still is implementation-hiding (today's lib code could be tomorrow's wrapper around a syscall, or vice versa; with a proper shared lib, the app would work either way). And also bug-fixing (dynamically linked apps benefit from shared lib bug fixes). The problem is dependencies. The problem is worse when you have open-source of the sort where binary compatibility isn't high on their agenda (or even source compatibility, sometimes); worse still when the version(s) bundled with [Open]Solaris are really old; and worse again when you have something like Blastwave, which for their own good reasons, builds so that as much as possible, the same packages work on Solaris 8 through the latest Solaris Express (although they _could_ have version- specific packages if they really needed to). In the latter case, they tend to supply their own versions of the libraries that may not be available on all Solaris versions they support, or where there may be library version issues. Solaris has a facility for versioning of symbols within a shared library (going back at least to Solaris 8, which is the earliest I have access to just now). However, (a) I don't know if the GNU versions of the linker, dynamic linker, and other ELF related code and utilities support that facility; and (b) it doesn't support incompatible (see http://docs.sun.com/app/docs/doc/816-0559/6m71o2afd?a=view) changes to the interface that a library exports. I have no idea what happens if you have two libraries of the same name on the RPATH (or other dynamic linker search order), but the first found does not have the needed version support while a later found one does. If that works out, and everyone used the versioning consistently, it might be possible to have system libs picked up if suitable, else app libs. If that doesn't work (just fails on system lib), then I don't see any existing solution that really has all the benefits. Static libs are _not_ good in general (due to lack of implementation-hiding and pickup of bugfixes). But a lot of duplicate libs isn't great either. There's no equivalent of DLL hell insofar as apps are built to require a search order that checks their own lib directory before the usual ones. But a lot of benefits are lost, and it's still a mess. IMO, _if_ OpenSolaris goes dual CDDL/GPLv3 _and_ most of the existing GPL code (other than the Linux kernel apparently, but that's not really an issue here) is GPLv2 _or_later_, that sharing of code (and other Sun or OpenSolaris-related participation in the external projects) might promote a little better discipline WRT binary compatibility issues in the larger open-source community. Maybe that's really the only thing that would help in the long run... This message posted from opensolaris.org
