On Mon, Aug 24, 2015 at 10:52 AM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> Thus if this newly reported problem is (as I am going to guess)
> in config/ompi_check_mx.m4 then it may go unfixed.
> You say you and I are the only ones to care, and I think we both care for
> reasons related to software quality rather than any desire to use MX.
>
I looked to see where the -rpath options are coming from.
I am 95% certain that libtool is constructing them from the
network-specific .la files (such as libfabric.la).
That is also the reason why libfabric gets linked by full path instead of a
"-l" option.
So, my conclusions:
1. Since there is no libmyriexpress.la, one should either
1a. add the MX libdir to LD_LIBRARY_PATH
1b. use the wrapper-ldflags family of configure arguments to add an
rpath
2. There is *probably* no Open MPI bug here assuming the authors of MX
support assumed "1a".
In support of these conclusion, the following is quoted from the MX
installation instructions:
For Linux, FreeBSD and Solaris, add the MX library directory to the
system library search path. Otherwise, individual users will have to
either manage their LD_LIBRARY_PATH(_64) environment variable or
link
their program with an "-rpath/-R" option for the dynamic linker to
locate the MX shared library.
So, I am actually wondering if Ralph's changes yesterday to "fix"
$(WRAPPER_EXTRA_LDFLAGS) might have been unnecessary.
Instead, I think *removing* those [testname]_LDFLAGS lines may be the
correct solution - they were *empty* until rc6.
IMHO: dropping MX support in 1.10 is probably wise given the lack of
vendor support .
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
