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

Reply via email to