don't try to build mpool/memkind component against memkind 1.4 or higher

[hppritcha]

The memkind API was complete rewritten in release 1.4 and is incompatible with the mpool/memkind in all release branches. Add a configury check to just not compile this component if memkind 1.4 or higher is installed.

[rhc54]

@hppritcha Looking at the memkind repo on github, it appears they have been fixing OMPI compile issues internally - they just aren't sharing the fixes. I'll smack them.

[ggouaillardet]

@rhc54 my understanding is Open MPI cannot be built with 1.4 <= memkind < 1.7, did I miss something ?

[rhc54]

Yes, changes were made to restore backward compatibility. I'm talking with them now.

[ggouaillardet]

The quickest way could be to have OPAL_CHECK_PACKAGE() test memkind_get_kind_by_partition() instead of memkind_malloc(). So we won't have to update our configure code if/when the change gets backported.

[rhc54]

I'm told that the memkind v1.7.0 release restores the compatibility fixes for OMPI. Waiting to find out when the distros will be picking it up (they now ship 1.4.0).

[rhc54]

Here is what I'm discovering. First, I'm trying to convey to them that they need to change the major release number when they break API - not sure that is getting thru, but I'm also given the feeling that there may not be any more memkind releases, or at least nothing anytime soon.

Second, it looks really risky to be using the "experimental" APIs we had in our earlier code, even with them being restored in 1.7.

Given that v1.4 is what is getting shipped in distros, and there is no way to know if/when that will be updated (heck, they didn't pick up 1.5 or 1.6 at all), I'd suggest the following:

1. update master to use the new official APIs in 1.4 and above
2. change the configury to look for a new API that didn't exist prior to 1.4, and disable memkind support if not found
3. backport that to at least the 3.0 series
4. if we want to do something for the 2.x series, I would just disable memkind