Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-09-14 18:45:49


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/