I take this back entirely -- ignore everything I said.
There appear to be two problems:
- I borked up the libnuma configure.m4 such that mpicc (and friends)
don't get the right flags for libnuma when you compile OMPI statically.
- James' problem seems to be somewhat different -- he's failing to link
ompi_info in the OMPI build itself, but also because the appropriate -L
and -l are not supplied. Although I can't get this to happen in any
version that I have (they always get the Right -L and -l to find
libnuma).
James: what command did you use to configure OMPI?
On Sep 14, 2005, at 7:45 PM, Jeff Squyres wrote:
On Sep 14, 2005, at 6:07 PM, Tim S. Woodall wrote:
Seriously, I can see your point, but I don't see an obvious fix -- we
don't check for the mode of the target library. We just check that
"$CC testprogram.c -L/path/to/libnuma -lnuma" works properly
(actually,
this is how *all* checks are done in OMPI -- libnuma is somewhat of
an
anomaly because most other packages/linux distros [depending on the
packaging] provide either just the .a or both the .a and the .so).
Brian / Ralf -- any ideas here?
Shouldn't the configure tests use the specified mode (e.g.
static/dynamic)?
Yes and no. They're not quite the same thing -- we setup libtool to
compile things in the desired mode(s), but libtool isn't really ready
until configure completes.
Brian and Ralf are the experts here...
Is there a short-term workaround to disable numa support for a static
build?
I'm guessing you had to specify --with-libnuma to find the library in
the first place...? If so, just don't specify it; if libnuma is not
in a standard location that is already searched by -L, then you'll
have no problem (i.e., the libnuma component's configure will fail and
it will automatically disqualify itself).
If, however, it does still find libnuma, you can specify
--enable-mca-no-build=maffinity-libnuma.
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
