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
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
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
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
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.
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
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
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
+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
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
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
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
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
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
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
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
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
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
18 matches
Mail list logo
