[OMPI devel] configure fails on the trunk since r31390

Folks, as reported in https://svn.open-mpi.org/trac/ompi/ticket/4521, configure fails on the trunk :-( Dear OpenMPI Folks, since r31390 , configure fails on the trunk because oshmem/include/pshmem.h.in in missing. i believe r31390

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

Yeah, that is a bad practice that should be fixed :-( I have no issue with the MCA param approach. As Jeff said, we have done similar things elsewhere, and the impact is limited solely to the places that need it. On Apr 14, 2014, at 1:12 PM, Mike Dubman wrote: > sorry, it is always 1:0:0 for

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

sorry, it is always 1:0:0 for all releases and not 0:0:0 as I mentioned. but still - it is always 1:0:0. agree that it is bad and ambiguous. The ofa claims that ABI does not change at all and verbs.h API/ABI is exactly as in spec for all toolkit generations. The non-spec experimental verbs infra a

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

hmm... very smart. thanks. seems it can work. will think about it more. On Mon, Apr 14, 2014 at 10:13 PM, Jeff Squyres (jsquyres) < jsquy...@cisco.com> wrote: > On Apr 14, 2014, at 2:57 PM, Mike Dubman wrote: > > > I think (+know) that many production environments and OMPI users will be > happy

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

this was true if all external libraries were maintaining ABI compatibility indicator properly with libtool. Let`s check your favorite, libibverbs :), the version is always 0.0.0 in libibverbs.so.0.0.0 so openib btl will not fail on link. The libibverbs can have experimental verbs included but libib

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

On Apr 14, 2014, at 3:27 PM, Mike Dubman wrote: > this was true if all external libraries were maintaining ABI compatibility > indicator properly with libtool. > Let`s check your favorite, libibverbs :), the version is always 0.0.0 in > libibverbs.so.0.0.0 so openib btl will not fail on link.

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

this was true if all external libraries were maintaining ABI compatibility indicator properly with libtool. Let`s check your favorite, libibverbs :), the version is always 0.0.0 in libibverbs.so.0.0.0 so openib btl will not fail on link. The libibverbs can have experimental verbs included but libib

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

this was true if all external libraries were maintaining ABI compatibility indicator properly with libtool. Let`s check your favorite, libibverbs :), the version is always 0.0.0 in libibverbs.so.0.0.0 so openib btl will not fail on link. The libibverbs can have experimental verbs included but libib

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

On Apr 14, 2014, at 2:57 PM, Mike Dubman wrote: > I think (+know) that many production environments and OMPI users will be > happy to have it. Agreed. Something like: char version_str[128]; snprintf(version_str, sizeof(version_str), "%d.%d.%d", libusnic_major, libusnic_m

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

+1. This is very helpful info to have. Best, Pavel (Pasha) Shamis On Apr 14, 2014, at 2:57 PM, Mike Dubman mailto:mi...@dev.mellanox.co.il>> wrote: sure, lets discuss it on the next telecon in 1w (Mellanox IL is OOO for holidays and Josh is on vacation). I think it is very good feature from e

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

sure, lets discuss it on the next telecon in 1w (Mellanox IL is OOO for holidays and Josh is on vacation). I think it is very good feature from enhancing OMPI usability point of view. See it as a programmable version of release notes, i.e. example: - In release notes vendors often specify that

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

BTW, I should point out that this really is only relevant if libfoo A.B.C and X.Y.Z are *ABI compatible*, but not *behavior compatible*. If A.B.C and X.Y.Z are not ABI compatible, then ompi_info will fail just like the MPI processes fail (i.e., it may not be able to dlopen the component using l

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

On Apr 14, 2014, at 10:59 AM, Mike Dubman wrote: > There is no correlation between built_with and running_with versions of > external libraries supported by OMPI. Ah, I see -- yes, that's the disconnect here. I think one use case that shows this is the following: 1. Admin Bob builds Open MPI

[OMPI devel] New open-mpi.org SSL certificates

IU has updated their SSL certificates. So you might/will be prompted to accept new certificates for SVN activity. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

Perhaps this is something best discussed on the weekly telecon? I think you are misunderstanding what I'm saying. I'm not heavily against it, but I still don't see the value, and dislike making disruptive changes that span the code base without first ensuring there is no other viable alternative

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

There is no correlation between built_with and running_with versions of external libraries supported by OMPI. The next release of external library does not mean we should remove code in ompi for all previous supported releases for the same library. vendor/site can certify slurm version 2.6.1 whil

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

On Apr 14, 2014, at 7:34 AM, Mike Dubman wrote: > it is unrelated: > > 1. The OMPI can support and built with many different (or all) versions of > external library (for example: libmxm or libslurm). Not true - we do indeed check the library version in all cases where it matters. For example

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

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

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

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 hav

Re: [OMPI devel] [devel-core] OMPI MCA components - track external libs versions

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, a

Re: [OMPI devel] OMPI MCA components - track external libs versions

+devel mailing list (for web mail archive) On Sat, Apr 12, 2014 at 9:04 PM, Mike Dubman 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_b