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/
