* Jeff Squyres wrote on Sat, Jul 25, 2009 at 07:59:25PM CEST: > On Jul 25, 2009, at 12:59 PM, Iain Bason wrote: > >> We have talked many times about doing proper versioning for > >> OMPI's .so libraries (e.g., libmpi.so -- *not* our component DSOs). > > > >Forgive me if this has been hashed out, but won't you run into trouble > >by not versioning the components? > > This is a good question; it has been discussed a few times, but it's > good to get it here on the web archives. More below.
Blissfully unaware of any prior discussion on this topic, I still cannot help but add my two cents here. :-) > >What happens when there are > >multiple versions of libmpi installed? The user program will pick up > >the correct one because of versioning, but how will libmpi pick up the > >correct versions of the components? > > Even with this shared library versioning, you will still only really > install one OMPI per directory tree anyway. The library versioning > won't allow you to install N different versions of OMPI in a single > tree because of multiple things: > > - support files are not versioned (e.g., show_help text files) > - include files are not versioned (e.g., mpi.h) > - OMPI's DSOs actually are versioned, but more work would be needed > in this area to make that versioning scheme work in real world > scenarios > - ...and probably some other things that I'm not thinking of... You can probably solve most of these issues by just versioning the directory names where you put the files; and with some luck, some downstream distribution can achieve this by merely passing a bunch of --foodir=... options to configure. That is to say, for modules that you actually dlopen, you could just ensure that the runtime loader doesn't find these by default, and then add some versioned directory to its search path for the right version of these files. (OMPI probably does all this already; can you tell I have no idea whether it does?) Cheers, Ralf
