On Tue, Apr 18, 2006 at 02:54:40PM -0700, David Leimbach wrote: > On 4/18/06, Roman Shaposhnick <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 18, 2006 at 12:22:30PM -0700, David Leimbach wrote: > > > On 4/18/06, Charles Forsyth <[EMAIL PROTECTED]> wrote: > > > The interesting thing is that Plan 9's great namespace manipulation > > > functionality + the fact that each process can have a private > > > namespace means that Plan 9 probably has the best shot at dealing with > > > "DLL-hell", like when 10 programs need 10 different versions of the > > > same shared library to run respectively. A simple script wrapped > > > around the loading of a program can set up a namespace such that > > > ambiguities don't exist. > > > > And you would have to go through all of the aforementioned troubles > > to achieve exactly what ? What is it, that shared libraries are good > > at ? > > #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.)
Perhaps. However, now that I've suffered my own share of .so madness by the virtue of working on Sun's C++ compiler, I really don't think that maintenance argument is a valid one. As always, it sounds good in theory, but as I've mentioned in my previous post an absolute lack of a decent management scheme kills it. The fix that benefits some application usually breaks others. What's even scarier is -- once broken they have to resort to LD_LIBRARY_PATH or some such to work around the issue. Not good. In a C++ case its even worse, because C++ runtime shared library is the worst of them all -- shared library other shared libraries might depend upon. It is really difficult to manage even the most trivial of cases: when a particular vendor distributes a C++ library as a shared object compiled with an older compiler and thus having a dependency on a previous generation of a C++ runtime shared library and later on the customer uses the latest version of a compiler only to discover the joys of mixing two version of a C++ runtime in one application. > #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. This one I might even agree with. However, there are much better ways of saving memory: kernel + file servers clients interact with would be the one. > I'm actually more concerned with #1 overall. And that's the problem. Once you start layering dependencies on top of each other -- you end up in a mess. I think the key issue here is that while it is safe to assume that you can control bits and pieces your application is built from during the build process itself, it is absolutely naive to assume that you have any guarantees of the same kind at a runtime if all that you give to a dynamic linker is just a name of an external entity (like a function call or a static variable). It sort of reminds me of the life in a flat file namespace, if you know what I mean. Painful and very difficult to manage right. Thanks, Roman.
