On Tue, 2008-01-29 at 19:39 +0000, Tang, Changqing wrote: > > > A runtime dlopen is different than being linked against a > > library, and yes in this case you would now have to > > dlopen(libdat2.so) and if that fails fall back to > > (libdat.so). However, given that according to the > > dapl-1 to dapl-2 porting guide there are several structures > > that have changed their layout between dat-1 and dat-2, I > > would think that HP-MPI would have to jump through hoops > > (either by knowing about both layouts, or by knowing what > > structures to avoid because they change) in order to support > > working with either dat-1 or dat-2 at runtime. If anything, > > that would make me think this is a good example of why they > > *should* be different library names. > > If there is a way to seamlessl work on either version available on the system > without asking user for choice, I am OK to change the library name.
I don't think there is. Dapl-1 and dapl-2 simply are not API compatible. You have to port to dapl-2 (or so the docs say, I haven't written any code that uses dapl, so I can't speak from experience). > According what you said, we can dlopen(libdat2.so) first, then fallback to > dlopen(libdat.so). > > But we have to claim that HP-MPI xxx version and older does not work with > uDAPL 2.0. You *should* be claiming that regardless. The API between dapl-1 and dapl-2 changed, some of which is fixed simply be recompiling and some of which requires actual code changes. Just because the library name is the same doesn't mean that code built and compiled against dapl-1 could or should attempt to run against dapl-2 (unless I'm wrong here, Arlin should really speak to this issue...if the dapl-2 libraries provide backward compatible symbols via so symbol versions, then it might be possible for a dapl-1 program to run against the dapl-2 library, but then that would beg the question of why we are still distributing dapl-1 libraries in a separate package, so I'm guessing there is not a back compatible layer in the dapl-2 library). > Currently HP-MPI works seamlessly on uDAPL 1.1 or uDAPL 1.2 system. Yes, and that's typical. Between minor point releases it's common that things "just work". Between major releases, it isn't. Between major releases it's common that at a minimum a recompile and relink is needed, but in this case you not only need a recompile and relink, but you need a few logical changes as well. It isn't plug-n-play for the dapl-1 to dapl-2 update. > > --CQ > > > > > --CQ > > > > > > > > > > > > > > > > > -arlin > > > > > > > > > > > > _______________________________________________ > > > > general mailing list > > > > [email protected] > > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > > > > > > > To unsubscribe, please visit > > > > http://openib.org/mailman/listinfo/openib-general > > > > > > -- > > Doug Ledford <[EMAIL PROTECTED]> > > GPG KeyID: CFBFF194 > > http://people.redhat.com/dledford > > > > Infiniband specific RPMs available at > > http://people.redhat.com/dledford/Infiniband > > -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
