I've answered this one for myself:
NO: the vader blt does not build on an SGI UV
However, xpmem support isn't detected at configure time either.
So, there is no "problem" here.
It might be nice to clarify in README that vader is for Cray's variant of XPMEM only.
++ Everything below this point is for the "future" milestone. ++
If one ever does want vader/xpmem support on the SGI UV, I see 2 issues to overcome:
SGI puts the header in /usr/include/sn/xpmem.h
There is no --with-xpmem= value that will let configure find the header in that location.
This is a "good thing" because if configure did find it, a build would fail be default due to issue #2.
To support SGI's xpmem will require additional configure logic to look for EITHER xpmem.h or sn/xpmem.h
To work past issue #1 I did:
$ mkdir $HOME/xpmem
$ ln -s /usr/include/sn $HOME/xpmem/include
and configured ompi using --with-xpmem=$HOME/xpmem
That allowed be to see the second issue...
There are some minor API differences in types in SGI's "flavor" of xpmem which cause the build to fail.
In GASNet we support both variants and the following snippet shows how we deal with the differences:
/* Cray XPMEM */
typedef struct xpmem_addr gasneti_xpmem_addr_t;
typedef xpmem_segid_t gasneti_xpmem_segid_t;
typedef xpmem_apid_t gasneti_xpmem_apid_t;
#define gasneti_xpmem_apid apid
/* SGI XPMEM */
typedef xpmem_addr_t gasneti_xpmem_addr_t;
typedef int64_t gasneti_xpmem_segid_t;
typedef int64_t gasneti_xpmem_apid_t;
#define gasneti_xpmem_apid id
+ Cray's "struct xpmem_addr" vs SGI's "xpmem_addr_t"
+ SGI's uses int64_t instead of defining xpmem_segid_t and xpmem_apid_t
+ SGI uses a struct member name of "id" vs Cray's "apid"
Note that the different locations for the header has worked to our benefit here by providing the variant detection mechanism without the need for configure probes for the types and members (though one could go that route if sufficiently paranoid about a variant between the two).