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