Looks like you are trying to link it against the 1.10 series? You could
probably get away with the symlink, but unless there is some reason to
avoid it, I'd just recompile to be safe.
On Wed, Sep 16, 2015 at 7:36 PM, Mark Moorcroft wrote:
>
>
> Hmm, I'm pretty sure my xhpl binary is/was dynamic
Hmm, I'm pretty sure my xhpl binary is/was dynamic linked. Here is my env:
LD_LIBRARY_PATH=/share/apps/openmpi-1.10-intel-x86_64/lib:/share/apps/Intel/composer_xe_2015.2.164/compiler/lib/intel64:/share/apps/Intel/composer_xe_2015.2.164/mkl/lib/intel64:/opt/python/lib
The binary fails without a sy
Jeff will undoubtedly start typing before he reads my response, so I'll
spare you from reading all the ugly details twice :-)
There was an unintentional ABI break in the 1.8 series that necessitated a
version numbering change to libmpi. It involves the code that handles the
connection between a pr
I found the thread below from May. I’m setting up a new cluster and using
openmpi 1.10. I have a gnu build and an Intel. Neither has libmpi.so.1. I
created a symlink and it’s working. My question is if I should try to
rebuild LAPACK, and is it wise to be adding that link? For me it’s just
burn-in a
