Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2005-09-16 04:01:05


Hi Jeff, Tim, James,

* Jeff Squyres wrote on Thu, Sep 15, 2005 at 02:55:26AM CEST:
>
> 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).

I must admit that I still have not understood the root of the problem.

> James: what command did you use to configure OMPI?

Yes, interesting question. :)

More comments below.

> 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).

> >> 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.

Two comments:
First, you don't want to force static vs dynamic mode while testing: for
the very reason, that when you create a program, it may just be fine for
you to link against some libraries statically and some dynamically.
Just don't try to create a shared library that links against a static
one.

Second, Jeff, libtool-1.5.x causes the `libtool' script to be output
right after its tests are done. libtool-2.x will not do this by
default, but may be forced to do so by calling the macro LT_INIT after
LT_INIT (aka AC_PROG_LIBTOOL). This will be documented, and you will be
able to maintain portability to both versions by using something like
  m4_ifdef([LT_OUTPUT], [LT_OUTPUT])
which calls the macro only if it is defined.
  
Cheers,
Ralf