Guess I'm a little confused and trying to understand the issue, so let's consider a couple of cases:
* If we are building against an unsupported version of an external library, that is supposed to be detected by the configure logic, yes? So you would output a nice error message at that time, and stop the build process. * If we were built against one version of an external library, and someone attempts to run us against a different version, you'd have to detect that somehow at runtime. I'm not sure how you could reliably do that as the problem is likely to manifest itself as an unresolved function (i.e., we use something that doesn't exist in the version being used) or a difference in a function signature. Either way, you'll either fail to load the library or crash. So I'm not sure what the added function pointer actually accomplishes. I suppose you could use it during ompi_info to display something about what version you linked against, but that won't help solve either of the above problems. Could you help explain a little further? Thanks Ralph On Apr 14, 2014, at 5:57 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > +devel mailing list (for web mail archive) > > > On Sat, Apr 12, 2014 at 9:04 PM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > Hi, > > Could you please suggest if following is addressed in MCA architecture or > maybe it is something we should add: > > Current MCA API: > The new MCA component should provide descriptor mca_base_component_2_0_0_t > which specifies how to init/open/close/query/enable every new component. > Also, the descriptor is used to specify version of MCA framework and version > of MCA component. > > What is missing: > Some MCA components are wrappers on top of external libraries, i.e. > > hwloc (libhwloc.so) > usnic (libusnic.so) > fca (libfca.so) > mxm (libmxm.so) > slurm (libslurn.so) > pbs > pmi > openib (libibverbs) > vader (knem, ...) > ... > > So, it would be very useful if MCA descriptor will have another function > pointer which return the version of external dependent library (if > applicable). > The ompi_info and oshmem_info will print it if present and will allow > sysadmin to track vendor specific dependencies for OMPI (like: mxm compiled > with libmxm 2.1, usnic with libusnic v1.0, ...) and warn users if compiled > versions do not match vendor recommended. > > Please suggest. > > Thanks > > > > > > > _______________________________________________ > devel-core mailing list > devel-c...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel-core
