Is there a libnuma.a on your system. If not the -static flag to ifort won't do any thing because there isn't a static library for it to link against.

Doug Reeder
On Mar 4, 2009, at 6:06 PM, Terry Frankcombe wrote:

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


users mailing list