On Jan 25, 2013, at 4:29 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> Ralph,
>
> LANL's platform file for the XE6 has enabled shared libs, which I must
> disable on our XC30 which is not setup for them.
I'm not sure why it does as we build everything strictly static on the XE6.
> So, I believe Nathan's text
>> A number of libraries (-lxpmem, -lugni, etc) are missing from libs_static.
>
> is the "borkedness" in mpicc, and shared-vs-static is probably why you don't
> have a problem on LANL's XE6.
I don't think so - I went ahead and disabled shared libs, and still get this in
mpicc:
ct-fe1 rcastain/openmpi-1.9a1> mpicc --showme
gcc
-I/usr/aprojects/hpctools/rhc/build/include/openmpi/opal/mca/hwloc/hwloc151/hwloc/include
-I/usr/aprojects/hpctools/rhc/build/include/openmpi/opal/mca/event/libevent2019/libevent
-I/usr/aprojects/hpctools/rhc/build/include/openmpi/opal/mca/event/libevent2019/libevent/include
-I/usr/aprojects/hpctools/rhc/build/include
-I/usr/aprojects/hpctools/rhc/build/include/openmpi -pthread -march=native
-L/opt/cray/ugni/2.3-1.0400.4127.5.20.gem/lib64
-L/opt/cray/xpmem/0.1-2.0400.30792.5.6.gem/lib64 -L/usr//lib64
-L/opt/cray/pmi/2.1.4-1.0000.8596.8.9.gem/lib64 -L/usr/lib/alps
-Wl,-rpath=/usr/lib64/alps
-Wl,-rpath=/opt/cray/pmi/2.1.4-1.0000.8596.8.9.gem/lib64
-Wl,-rpath=/opt/cray/ugni/2.3-1.0400.4127.5.20.gem/lib64
-Wl,-rpath=/opt/cray/xpmem/0.1-2.0400.30792.5.6.gem/lib64
-L/usr/aprojects/hpctools/rhc/build/lib -lmpi -lugni -lxpmem -llustre
-llustreapi -lrt -lnsl -lutil -lm -ldl -lpmi -lalpslli -lalpsutil -lrt -lnsl
-lutil -lm -lnsl -lutil -lm -lopen-rte -ldl -lpmi -lalpslli -lalpsutil -lrt
-lnsl -lutil -lm -lnsl -lutil -lm -lopen-pal -ldl -lpmi -lalpslli -lalpsutil
-lrt -lnsl -lutil -lm -lnsl -lutil -lm
The repeated libs is something we obviously should fix, but all the libs are
there - including lustre. I guess those were dropped due to the shared lib
setting, so we probably should fix that in the platform file.
Perhaps that is the cause of Nathan's issue? shrug...regardless, apps build and
run just fine using mpicc for me.
>
> -Paul
>
>
> On Fri, Jan 25, 2013 at 4:09 PM, Ralph Castain <r...@open-mpi.org> wrote:
> FWIW: I can build it fine without setting any of the CC... flags on LANL's
> Cray XE6, and mpicc worked just fine for me once built that way.
>
> So I'm not quite sure I understand the "mpicc is completely borked in the
> trunk". Can you elaborate?
>
> On Jan 25, 2013, at 3:59 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>
>> Nathan,
>>
>> The 2nd and 3rd non-blank lines of my original post:
>> Given that it is INTENDED to be API-compatible with the XE series, I began
>> configuring with
>> CC=cc CXX=CC FC=ftn --with-platform=lanl/cray_xe6/optimized-nopanasas
>>
>> So, I am surprised that nobody objected before now to my use of the
>> Cray-provided wrapper compilers.
>> I mistakenly believed that if I don't use them then I wouldn't get through
>> configure w/ ugni and alps support.
>> However, I've just now completed configure w/o setting CC, CXX, FC and see
>> the expected components.
>> I'll report more from this build later ("make all" is running now).
>>
>> I would appreciate (perhaps off-list) receiving any module or platform file
>> or additional instructions that maybe appropriate to building on a Cray XE,
>> XK or XC system.
>>
>> Getting OMPI running on our XC30 is of exactly ZERO importance beyond my own
>> edification.
>> So, I am likely to stop fighting this battle soon.
>>
>> -Paul
>>
>>
>> On Fri, Jan 25, 2013 at 3:21 PM, Nathan Hjelm <hje...@lanl.gov> wrote:
>> Hmm, I see mpicc in there. It will use the compiler directly instead of
>> Cray's wrappers. We didn't want Open MPI's wrapper linking in MPT afterall
>> ;). mpicc is completely borked in the trunk.
>>
>> If you want to use the Cray wrappers with Open MPI I can give you a module
>> file that sets up the environment correctly (link against -lmpi not -lmpich,
>> etc).
>>
>> -Nathan
>>
>> On Fri, Jan 25, 2013 at 03:10:37PM -0800, Paul Hargrove wrote:
>> > Nathan,
>> >
>> > Cray's "cc" wrapper is adding xpmem, ugni, pmi, alps and others already:
>> >
>> > $ cc -v hello.c 2>&1 | grep collect
>> > > /opt/gcc/4.7.2/snos/libexec/gcc/x86_64-suse-linux/4.7.2/collect2
>> > > --sysroot= -m elf_x86_64 -static -u pthread_mutex_trylock -u
>> > > pthread_mutex_destroy -u pthread_create /usr/lib/../lib64/crt1.o
>> > > /usr/lib/../lib64/crti.o
>> > > /opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/crtbeginT.o
>> > > -L/opt/cray/udreg/2.3.2-1.0500.5931.3.1.ari/lib64
>> > > -L/opt/cray/ugni/4.0-1.0500.5836.7.58.ari/lib64
>> > > -L/opt/cray/pmi/4.0.0-1.0000.9282.69.4.ari/lib64
>> > > -L/opt/cray/dmapp/4.0.1-1.0500.5932.6.5.ari/lib64
>> > > -L/opt/cray/xpmem/0.1-2.0500.36799.3.6.ari/lib64
>> > > -L/opt/cray/alps/5.0.1-2.0500.7663.1.1.ari/lib64
>> > > -L/opt/cray/rca/1.0.0-2.0500.37705.3.12.ari/lib64
>> > > -L/opt/cray/mpt/5.6.0/gni/mpich2-gnu/47/lib
>> > > -L/opt/cray/mpt/5.6.0/gni/sma/lib64
>> > > -L/opt/cray/libsci/12.0.00/gnu/47/sandybridge/lib
>> > > -L/opt/cray/alps/5.0.1-2.0500.7663.1.1.ari/lib64
>> > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2
>> > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/../../../../lib64
>> > > -L/lib/../lib64 -L/usr/lib/../lib64
>> > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/../../..
>> > > /scratch1/scratchdirs/hargrove/ccQ1f0sx.o -lrca
>> > > -L/opt/cray/atp/1.6.0/lib/
>> > > --undefined=_ATP_Data_Globals --undefined=__atpHandlerInstall
>> > > -lAtpSigHCommData -lAtpSigHandler --start-group -lgfortran -lscicpp_gnu
>> > > -lsci_gnu_mp -lstdc++ -lgfortran -lmpich_gnu_47 -lmpl -lrt -lsma -lxpmem
>> > > -ldmapp -lugni -lpmi -lalpslli -lalpsutil -lalps -ludreg -lpthread -lm
>> > > --end-group -lgomp -lpthread --start-group -lgcc -lgcc_eh -lc --end-group
>> > > /opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/crtend.o
>> > > /usr/lib/../lib64/crtn.o
>> >
>> >
>> > -Paul
>> >
>> >
>> > On Fri, Jan 25, 2013 at 2:46 PM, Nathan Hjelm <hje...@lanl.gov> wrote:
>> >
>> > > Something is wrong with the wrappers. A number of libraries (-lxpmem,
>> > > -lugni, etc) are missing from libs_static. Might be a similar issue with
>> > > eh
>> > > missing -llustreapi. Going to create a critical bug to track this issue.
>> > >
>> > > Works in 1.7 :-/ ... If you add -lnuma to libs_static in
>> > > mpicc-wrapper-data.txt.
>> > >
>> > > -Nathan
>> > > HPC-3, LANL
>> > >
>> > > On Fri, Jan 25, 2013 at 02:13:41PM -0800, Paul Hargrove wrote:
>> > > > Still having problems on the Cray XC30, but now they are when linking
>> > > > an
>> > > > MPI app:
>> > > >
>> > > > $ ./INSTALL/bin/mpicc -o ring_c examples/ring_c.c
>> > > > > fs_lustre_file_open.c:(.text+0x130): undefined reference to
>> > > > > `llapi_file_create'
>> > > > > fs_lustre_file_open.c:(.text+0x17e): undefined reference to
>> > > > > `llapi_file_get_stripe'
>> > > > > /usr/bin/ld: link errors found, deleting executable `ring_c'
>> > > > > collect2: error: ld returned 1 exit status
>> > > >
>> > > >
>> > > > It appears that lustre support was found at configure time using a test
>> > > > that used "-llustre -llusterapi":
>> > > >
>> > > > > configure:157666: checking if possible to link LUSTRE
>> > > > > configure:157680: cc -std=gnu99 -o conftest -O3 -DNDEBUG
>> > > > > -finline-functions -fno-strict-aliasing -fexceptions -D_REENTRANT
>> > > > >
>> > > -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/hwloc/hwloc151/hwloc/include
>> > > > >
>> > > -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison/opal/mca/hwloc/hwloc151/hwloc/include
>> > > > >
>> > > -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent
>> > > > >
>> > > -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/opal/mca/event/libevent2019/libevent/include
>> > > > >
>> > > -I/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/BUILD-edison/opal/mca/event/libevent2019/libevent/include
>> > > > > -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include
>> > > > > -I/opt/cray/pmi/default/include -I/opt/cray/pmi/default/include
>> > > > > -I/usr//include/lustre/ -fexceptions -L/usr//lib64 conftest.c
>> > > > > -lnsl
>> > > > > -lutil -lnsl -lutil -llustre -llustreapi
>> > > >
>> > > >
>> > > > However, those two libs are NOT included when linking an MPI
>> > > > application:
>> > > >
>> > > > > $ ./INSTALL/bin/mpicc -o ring_c examples/ring_c.c -v 2>&1 | grep
>> > > collect
>> > > > > /opt/gcc/4.7.2/snos/libexec/gcc/x86_64-suse-linux/4.7.2/collect2
>> > > > > --sysroot= -m elf_x86_64 -static -o ring_c -u pthread_mutex_trylock
>> > > > > -u
>> > > > > pthread_mutex_destroy -u pthread_create /usr/lib/../lib64/crt1.o
>> > > > > /usr/lib/../lib64/crti.o
>> > > > > /opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/crtbeginT.o
>> > > > > -L/opt/cray/pmi/default/lib64 -L/opt/cray/alps/default/lib64
>> > > > >
>> > > -L/global/homes/h/hargrove/GSCRATCH/OMPI/openmpi-1.9a1r27905/INSTALL/lib
>> > > > > -L/opt/cray/udreg/2.3.2-1.0500.5931.3.1.ari/lib64
>> > > > > -L/opt/cray/ugni/4.0-1.0500.5836.7.58.ari/lib64
>> > > > > -L/opt/cray/pmi/4.0.0-1.0000.9282.69.4.ari/lib64
>> > > > > -L/opt/cray/dmapp/4.0.1-1.0500.5932.6.5.ari/lib64
>> > > > > -L/opt/cray/xpmem/0.1-2.0500.36799.3.6.ari/lib64
>> > > > > -L/opt/cray/alps/5.0.1-2.0500.7663.1.1.ari/lib64
>> > > > > -L/opt/cray/rca/1.0.0-2.0500.37705.3.12.ari/lib64
>> > > > > -L/opt/cray/mpt/5.6.0/gni/mpich2-gnu/47/lib
>> > > > > -L/opt/cray/mpt/5.6.0/gni/sma/lib64
>> > > > > -L/opt/cray/libsci/12.0.00/gnu/47/sandybridge/lib
>> > > > > -L/opt/cray/alps/5.0.1-2.0500.7663.1.1.ari/lib64
>> > > > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2
>> > > > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/../../../../lib64
>> > > > > -L/lib/../lib64 -L/usr/lib/../lib64
>> > > > > -L/opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/../../..
>> > > > > /scratch1/scratchdirs/hargrove/cceRJNtp.o -lmpi -lpmi -lalpslli
>> > > -lalpsutil
>> > > > > -lnsl -lutil -lnsl -lutil -lopen-rte -lpmi -lalpslli -lalpsutil -lnsl
>> > > > > -lutil -lnsl -lutil -lopen-pal -lpmi -lalpslli -lalpsutil -lnsl
>> > > > > -lutil
>> > > > > -lnsl -lutil -lrca -L/opt/cray/atp/1.6.0/lib/
>> > > --undefined=_ATP_Data_Globals
>> > > > > --undefined=__atpHandlerInstall -lAtpSigHCommData -lAtpSigHandler
>> > > > > --start-group -lgfortran -lscicpp_gnu -lsci_gnu_mp -lstdc++
>> > > > > -lgfortran
>> > > > > -lmpich_gnu_47 -lmpl -lrt -lsma -lxpmem -ldmapp -lugni -lpmi
>> > > > > -lalpslli
>> > > > > -lalpsutil -lalps -ludreg -lpthread -lm --end-group -lgomp -lpthread
>> > > > > --start-group -lgcc -lgcc_eh -lc --end-group
>> > > > > /opt/gcc/4.7.2/snos/lib/gcc/x86_64-suse-linux/4.7.2/crtend.o
>> > > > > /usr/lib/../lib64/crtn.o
>> > > > > collect2: error: ld returned 1 exit status
>> > > >
>> > > >
>> > > > Of course the obvious work-around to try is adding "-llustre
>> > > > -llustreapi"
>> > > > to my command line. However, that doesn't work because mpicc places my
>> > > > "-l" args BEFORE its own "-lmpi". Since "-static" is also among the
>> > > > arguments, no symbols are picked up from the luster libs when they
>> > > > appear
>> > > > on the command line before "-lmpi", from which lustre symbols are
>> > > > referenced.
>> > > >
>> > > > Best guess(es):
>> > > > EITHER config/ompi_check_lustre.m4 is failing to add "-llustre
>> > > -llustreapi"
>> > > > to some variable
>> > > > OR the variable set by config/ompi_check_lustre.m4 isn't making its way
>> > > > into the application link command for some reason
>> > > >
>> > > > Note that this is a --disable-shared/--enable-static build which may
>> > > differ
>> > > > from other systems where LUSTRE support gets used/tested.
>> > > >
>> > > > -Paul
>> > > >
>> > > >
>> > > > On Fri, Jan 25, 2013 at 12:01 PM, Ralph Castain <r...@open-mpi.org>
>> > > wrote:
>> > > >
>> > > > > Thanks Paul
>> > > > >
>> > > > > I'm currently tracking down a problem on the Cray XE6 - it appears
>> > > > > that
>> > > > > recent OS release changed the way alps stores allocation info :-(
>> > > > >
>> > > > > Will hopefully have it running soon.
>> > > > >
>> > > > > On Jan 25, 2013, at 10:50 AM, Paul Hargrove <phhargr...@lbl.gov>
>> > > wrote:
>> > > > >
>> > > > > I was able to compile with openmpi-1.9a1r27905.tar.bz
>> > > > >
>> > > > > I'll report again when I've had an opportunity to run something like
>> > > > > ring_c.
>> > > > >
>> > > > > Thanks,
>> > > > > -Paul
>> > > > >
>> > > > >
>> > > > > On Tue, Jan 22, 2013 at 6:08 PM, Ralph Castain <r...@open-mpi.org>
>> > > wrote:
>> > > > >
>> > > > >> I went ahead and removed the duplicate code, so this should work
>> > > > >> now.
>> > > The
>> > > > >> problem is that we re-factored the ompi_info/orte-info code, but
>> > > didn't
>> > > > >> complete the job - specifically, the orte-info tool didn't get
>> > > updated.
>> > > > >> It's about to get revamped yet again when the ompi-rte branch gets
>> > > > >> committed to the trunk, so I'd rather not do any more with it now.
>> > > > >>
>> > > > >> Hopefully, this will be the minimum required.
>> > > > >>
>> > > > >>
>> > > > >> On Jan 22, 2013, at 4:20 PM, Paul Hargrove <phhargr...@lbl.gov>
>> > > wrote:
>> > > > >>
>> > > > >> I am using the openmpi-1.9a1r27886 tarball and I still see an error
>> > > for
>> > > > >> one of the two duplicate symbols:
>> > > > >>
>> > > > >> CCLD orte-info
>> > > > >> ../../../orte/.libs/libopen-rte.a(orte_info_support.o): In function
>> > > > >> `orte_info_show_orte_version':
>> > > > >> ../../orte/runtime/orte_info_support.c:(.text+0xe10): multiple
>> > > definition
>> > > > >> of `orte_info_show_orte_version'
>> > > > >> version.o:../../../../orte/tools/orte-info/version.c:(.text+0x2370):
>> > > > >> first defined here
>> > > > >>
>> > > > >> -Paul
>> > > > >>
>> > > > >>
>> > > > >> On Fri, Jan 18, 2013 at 3:52 AM, George Bosilca <bosi...@icl.utk.edu
>> > > >wrote:
>> > > > >>
>> > > > >>> Luckily for us all the definitions contain the same constant
>> > > > >>> (orte).
>> > > > >>> r27864 should fix this.
>> > > > >>>
>> > > > >>> George.
>> > > > >>>
>> > > > >>>
>> > > > >>> On Jan 18, 2013, at 06:21 , Paul Hargrove <phhargr...@lbl.gov>
>> > > wrote:
>> > > > >>>
>> > > > >>> My employer has a nice new Cray XC30 (aka Cascade), and I thought
>> > > > >>> I'd
>> > > > >>> give Open MPI a quick test.
>> > > > >>>
>> > > > >>> Given that it is INTENDED to be API-compatible with the XE series,
>> > > > >>> I
>> > > > >>> began configuring with
>> > > > >>> CC=cc CXX=CC FC=ftn
>> > > --with-platform=lanl/cray_xe6/optimized-nopanasas
>> > > > >>> However, since this is Intel h/w, I commented-out the following 2
>> > > lines
>> > > > >>> in the platform file:
>> > > > >>> with_wrapper_cflags="-march=amdfam10"
>> > > > >>> CFLAGS=-march=amdfam10
>> > > > >>>
>> > > > >>> I am using PrgEnv-gnu/5.0.15, though PrgEnv-intel is the default on
>> > > our
>> > > > >>> system
>> > > > >>>
>> > > > >>> As far as I know, use of 1.6.x is out - no ugni at all, right?
>> > > > >>> So, I didn't even try.
>> > > > >>>
>> > > > >>> I gave openmpi-1.7rc6 a try, but the ALPS headers and libs have
>> > > > >>> moved
>> > > > >>> (as mentioned in ompi-trunk/config/orte_check_alps.m4).
>> > > > >>> Perhaps one should CMR the updated-for-CLE-5 configure logic to the
>> > > 1.7
>> > > > >>> branch?
>> > > > >>>
>> > > > >>> Next, I tried a trunk nightly tarball: openmpi-1.9a1r27862.tar.bz2
>> > > > >>> As I mentioned above, the trunk has the right logic for locating
>> > > ALPS.
>> > > > >>> However, it looks like there is some untested code, protected by
>> > > > >>> "#if
>> > > > >>> WANT_CRAY_PMI2_EXT", that needs work:
>> > > > >>>
>> > > > >>> make[2]: Entering directory
>> > > > >>>
>> > > `/global/scratch/sd/hargrove/OMPI/openmpi-1.9a1r27862/BUILD/orte/mca/db/pmi'
>> > > > >>> CC db_pmi_component.lo
>> > > > >>> CC db_pmi.lo
>> > > > >>> ../../../../../orte/mca/db/pmi/db_pmi.c: In function 'store':
>> > > > >>> ../../../../../orte/mca/db/pmi/db_pmi.c:202: error: 'ptr'
>> > > > >>> undeclared
>> > > > >>> (first use in this function)
>> > > > >>> ../../../../../orte/mca/db/pmi/db_pmi.c:202: error: (Each
>> > > > >>> undeclared
>> > > > >>> identifier is reported only once
>> > > > >>> ../../../../../orte/mca/db/pmi/db_pmi.c:202: error: for each
>> > > function it
>> > > > >>> appears in.)
>> > > > >>> make[2]: *** [db_pmi.lo] Error 1
>> > > > >>> make[2]: Leaving directory
>> > > > >>>
>> > > `/global/scratch/sd/hargrove/OMPI/openmpi-1.9a1r27862/BUILD/orte/mca/db/pmi'
>> > > > >>> make[1]: *** [all-recursive] Error 1
>> > > > >>> make[1]: Leaving directory
>> > > > >>> `/global/scratch/sd/hargrove/OMPI/openmpi-1.9a1r27862/BUILD/orte'
>> > > > >>> make: *** [all-recursive] Error 1
>> > > > >>>
>> > > > >>> I added the missing "char *ptr" declaration a few lines before it's
>> > > > >>> first use, and resumed the build.
>> > > > >>> This time the build terminated at
>> > > > >>>
>> > > > >>> make[2]: Entering directory
>> > > > >>>
>> > > `/global/scratch/sd/hargrove/OMPI/openmpi-1.9a1r27862/BUILD/opal/tools/wrappers'
>> > > > >>> CC opal_wrapper.o
>> > > > >>> CCLD opal_wrapper
>> > > > >>> /usr/bin/ld: attempted static link of dynamic object
>> > > > >>> `../../../opal/.libs/libopen-pal.so'
>> > > > >>> collect2: error: ld returned 1 exit status
>> > > > >>>
>> > > > >>> So I went back to the platform file and changed
>> > > > >>> enable_shared=yes
>> > > > >>> to
>> > > > >>> enable_shared=no
>> > > > >>> No big deal there - I had to make the same change for our XE6.
>> > > > >>>
>> > > > >>> And so I started back at configure (after a "make distclean", to be
>> > > > >>> safe), and here is the next error:
>> > > > >>>
>> > > > >>> Making all in tools/orte-info
>> > > > >>> make[2]: Entering directory
>> > > > >>>
>> > > `/global/scratch/sd/hargrove/OMPI/openmpi-1.9a1r27862/BUILD/orte/tools/orte-info'
>> > > > >>> CCLD orte-info
>> > > > >>> ../../../orte/.libs/libopen-rte.a(orte_info_support.o): In function
>> > > > >>> `orte_info_show_orte_version':
>> > > > >>> orte_info_support.c:(.text+0xd70): multiple definition of
>> > > > >>> `orte_info_show_orte_version'
>> > > > >>> version.o:version.c:(.text+0x4b0): first defined here
>> > > > >>> ../../../orte/.libs/libopen-rte.a(orte_info_support.o):(.data+0x0):
>> > > > >>> multiple definition of `orte_info_type_orte'
>> > > > >>> orte-info.o:(.data+0x10): first defined here
>> > > > >>> /usr/bin/ld: link errors found, deleting executable `orte-info'
>> > > > >>> collect2: error: ld returned 1 exit status
>> > > > >>> make[2]: *** [orte-info] Error 1
>> > > > >>>
>> > > > >>> I am not sure how to fix this, but I would guess this is probably a
>> > > > >>> simple fix for somebody who knows OMPI's build infrastructure
>> > > > >>> better
>> > > than I.
>> > > > >>>
>> > > > >>> -Paul
>> > > > >>>
>> > > > >>> --
>> > > > >>> Paul H. Hargrove phhargr...@lbl.gov
>> > > > >>> Future Technologies Group
>> > > > >>> Computer and Data Sciences Department Tel: +1-510-495-2352
>> > > > >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> > > > >>> _______________________________________________
>> > > > >>> devel mailing list
>> > > > >>> de...@open-mpi.org
>> > > > >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> _______________________________________________
>> > > > >>> devel mailing list
>> > > > >>> de...@open-mpi.org
>> > > > >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> Paul H. Hargrove phhargr...@lbl.gov
>> > > > >> Future Technologies Group
>> > > > >> Computer and Data Sciences Department Tel: +1-510-495-2352
>> > > > >> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> > > > >> _______________________________________________
>> > > > >> devel mailing list
>> > > > >> de...@open-mpi.org
>> > > > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> _______________________________________________
>> > > > >> devel mailing list
>> > > > >> de...@open-mpi.org
>> > > > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Paul H. Hargrove phhargr...@lbl.gov
>> > > > > Future Technologies Group
>> > > > > Computer and Data Sciences Department Tel: +1-510-495-2352
>> > > > > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> > > > > _______________________________________________
>> > > > > devel mailing list
>> > > > > de...@open-mpi.org
>> > > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > devel mailing list
>> > > > > de...@open-mpi.org
>> > > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Paul H. Hargrove phhargr...@lbl.gov
>> > > > Future Technologies Group
>> > > > Computer and Data Sciences Department Tel: +1-510-495-2352
>> > > > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> > >
>> > > > _______________________________________________
>> > > > devel mailing list
>> > > > de...@open-mpi.org
>> > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > >
>> > > _______________________________________________
>> > > devel mailing list
>> > > de...@open-mpi.org
>> > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> > >
>> >
>> >
>> >
>> > --
>> > Paul H. Hargrove phhargr...@lbl.gov
>> > Future Technologies Group
>> > Computer and Data Sciences Department Tel: +1-510-495-2352
>> > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>
>> > _______________________________________________
>> > devel mailing list
>> > de...@open-mpi.org
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>>
>> --
>> Paul H. Hargrove phhargr...@lbl.gov
>> Future Technologies Group
>> Computer and Data Sciences Department Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
