it is unrelated: 1. The OMPI can support and built with many different (or all) versions of external library (for example: libmxm or libslurm). 2. The OMPI utility ompi_info can expose the currently available version of libmxm/libslurm.
3. The vendor or end-user wants to certify specific version of libmxm or libslurm to be used in the customer environment. 4. The current way - put a note into libmxm/libslurm Relase Notes, which is not a guarantee that site user/sysadmin will pay attention in production environment. 5. The suggestion is to use #2 to write script by user or vendor which will match currently available versions with supported/certified and let admin/user know that there is a mismatch between running and supported version. P.S. based on the true story :) On Mon, Apr 14, 2014 at 5:19 PM, Ralph Castain <r...@open-mpi.org> wrote: > <let's be consistent and shift this to the devel list> > > I'm still confused - how is that helpful? How was the build allowed to > complete if the external library version isn't supported?? You should > either quietly not-build the affected component, or error out if the user > specifically requested that component be built. > > This sounds to me like you have a weakness in your configure logic, and > are trying to find a bandaid. Perhaps a better solution (that wouldn't > cause us to change every component in the code base) would be to just add > appropriate tests to your configure logic so you don't incorrectly build > against an unsupported library? > > > On Apr 14, 2014, at 7:12 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > > The use-case I`m interested to expose through ompi_info/oshmem_info the > compiled-in versions of external libraries. > User/Vendor can write small script on top of ompi_info/oshmem_info to > check if running version are in par with supported matrix. > > > On Mon, Apr 14, 2014 at 5:06 PM, Ralph Castain <r...@open-mpi.org> wrote: > >> 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 >> >> >> >> _______________________________________________ >> devel-core mailing list >> devel-c...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel-core >> > > _______________________________________________ > devel-core mailing list > devel-c...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel-core > > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14507.php >
