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