LAM does not know anything about udapl, so I'm not sure how you could
be generating these messages unless you are somehow mixing MPI
implementations (perhaps mixing Open MPI and LAM/MPI somehow? Even
so; Open MPI doesn't build udapl by default on Linux because it
prefers native verbs support).
Note that the "make check" mechanism in the Open MPI SVN version of
the ibm test suite is not used much; it may or may not be 100%
functional (i.e., it may have bit rotted over time). I typically use
the MPI Testing Tool (MTT) to run all the IBM tests; MTT is much more
reliable and flexible. MTT finds all the executables that were
generated by "make" and runs them by itself, not via "make check".
For example, here's Cisco's Open MPI testing results from the IBM test
suite from yesterday:
http://www.open-mpi.org/mtt/index.php?do_redir=868
On Oct 17, 2008, at 3:55 AM, Steven wrote:
> Hi Tim and Jeff:
>
> You are right that I combined some *.o files into my compiling
> server. These objective files were compiled on differnt enviroment,
> which resulted in the issue. I removed them and rerun make. This
> time make or make -k is clear. When I run "make -k check", the
> output has continous warning such as
>
> WARNING: Failed to open
> "ib0" [DAT_PROVIDER_NOT_FOUND:DAT_NAME_NOT_REGISTERED].
> This may be a real error or it may be an invalid entry in the uDAPL
> Registry which is contained in the dat.conf file. Contact your local
> System Administrator to confirm the availability of the interfaces in
> the dat.conf file.
>
> My servers have one Infiniband ConnectX adapter connected. It looks
> that lamtest will detect the IB network. At the output end of "make -
> k check", it wrote
>
> PASS: sub
> ==================
> All 4 tests passed
>
> I am not sure how many test cases have been executed (only four
> cases?). And whether 100% of them has succeeded or not.
>
> Thanks a lot for your attetion!
>
> Steven Wang
> ÔÚ2008-10-16£¬"Tim Prince" <TimothyPrince_at_[hidden]> дµÀ£º
> >Steven wrote:
> >> I got lamtest from https://svn.open-mpi.org/svn/ompi-tests/trunk/ibm
> to compile on SLES10 SP2 x86_64.
> >>
> >> make or make -k failed in pt2pt directory:
> >>
> >> linux:/LTC/ompi_lamtests/pt2pt # make
> >> mpif77 -o sendrecv_f sendrecv_f.o -L../reporting -lompitest
> >> /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-
> linux/bin/ld: warning: i386 architecture of input file
> `sendrecv_f.o' is incompatible with i386:x86-64 output
> >> sendrecv_f.o: In function `MAIN__':
> >> sendrecv_f.f:(.text+0xa): undefined reference to
> `__intel_new_proc_init'
> >> sendrecv_f.f:(.text+0x14): undefined reference to
> `for_set_reentrancy'
> >> sendrecv_f.f:(.text+0x205): undefined reference to `for_stop_core'
> >> collect2: ld returned 1 exit status
> >> make: *** [sendrecv_f] Error 1
> >>
> >You can't mix 32- and 64-bit compilation modes. If you are mixing
> gcc
> >with ifort, you must use the /fce/ or /intel64/ directory versions
> of
> >ifort (and the associated PATH settings) together with gcc (default
> -m64),
> >or the /fc/ or /ia32/ ifort together with gcc -m32.
> >It looks like you used 64-bit gcc with 32-bit ifort.
> >You would have to build and test lam with the same setup. You
> would not
> >be able to use a gnu Fortran for part of the job, if you ever use
> ifort.
> >In order to keep 32- and 64-bit lam installations apart, you might
> remove
> >any lam installation which came with suse (as it won't work with
> ifort),
> >and build and install your own lam, choosing separate --prefix,
> such as
> >/usr/local/lam64 and /usr/local/lam32.
>
>
> [¹ã¸æ] Ìػݳ¢±Øʤ¿Í26µÀÐÂÆ·
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
--
Jeff Squyres
Cisco Systems
|
