Thanks to everyone who contributed.
I no longer think this is Open MPI's problem. This system is just
stupid. Everything's 64 bit (which various probes with file confirm).
There's no icc, so I can't test with that. gcc finds libnuma without
-L. (Though a simple gcc -lnuma -Wl,-t reports that libnuma is found
through the rather convoluted
path /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../lib64/libnuma.so.)
ifort -lnuma can't find libnuma.so, but then ifort -L/usr/lib64 -lnuma
can't find it either! While everything else points to some mix up with
linking search paths, that last result confuses me greatly. (Unless
there's some subtlety with libnuma.so being a link to libnuma.so.1.)
I can compile my app by replicating mpif90's --showme output directly on
the command line, with -lnuma replaced explicitly
with /usr/lib64/libnuma.so. Then, even though I've told ifort -static,
ldd gives the three lines:
libnuma.so.1 => /usr/lib64/libnuma.so.1 (0x00002b3f58a3c000)
libc.so.6 => /lib64/tls/libc.so.6 (0x00002b3f58b42000)
/lib/ld64.so.1 => /lib/ld64.so.1 (0x00002b3f58925000)
While I don't understand what's going on here, I now have a working
binary. It's the only app I use on this machine, so I'm no longer
concerned. All other machines on which I use Open MPI work as expected
out of the box. My workaround here is sufficient.
Once more, thanks for the suggestions. I think this machine is just
pathological.
Ciao
Terry
