It sounds like you might not have the blcr components properly
built. Can you make sure the components are actually loaded by
looking at the output of laminfo? If there is not a blcr cr
component listed, then there is no blcr support in your build. At
that point, it would be useful to look at the output of configure and/
or the config.log from the top source directory and the one from
share/ssi/crlam/blcr/.
Brian
On Dec 27, 2005, at 1:22 AM, Liu Xuezhao wrote:
> Ok, i have test that case over lam-7.1.1 and lam-7.1.2b30. I
> config them with the same option as lam-7.0.6. When executing
> "mpirun -np 2 ****", there aren't "/tmp/lam-xxx_at_node01/lam-crtcp-
> rank-0.txt" file then. But there is another problem with lam-7.1.1
> and 7.1.2b30, the application compiled by mpicc is not dependent on
> the blcr library.
> I config lam-7.0.6 and lam-7.1.1 with the same command:
> /configure --with-blcr=/home/lxz/opt/blcr \
> --with-cr-file-dir=/home/lxz/tmp \
> --with-rpi=crtcp \
> --prefix=/home/lxz/opt/lam-7.x.x \
> --with-rsh="ssh -x"
> make ; make install
> use the ldd utility can print the shared library dependencies of
> the mpicc:
> lxz_at_ganode004:~/src/HPL/hpl> ldd /home/lxz/opt/lam-7.0.6/bin/mpicc
> libcr.so.0 => /home/lxz/opt/blcr/lib/libcr.so.0
> (0x0000002a9566d000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95791000)
> libpthread.so.0 => /lib64/tls/libpthread.so.0
> (0x0000002a95894000)
> libutil.so.1 => /lib64/libutil.so.1 (0x0000002a959a8000)
> libstdc++.so.5 => /usr/lib64/libstdc++.so.5
> (0x0000002a95aac000)
> libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95c89000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a95de0000)
> libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95eec000)
> /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
> (0x0000002a95556000)
> lxz_at_ganode004:~/src/HPL/hpl> ldd /home/lxz/opt/lam-7.1.1/bin/mpicc
> libdl.so.2 => /lib64/libdl.so.2 (0x0000002a9566d000)
> libutil.so.1 => /lib64/libutil.so.1 (0x0000002a95770000)
> libstdc++.so.5 => /usr/lib64/libstdc++.so.5
> (0x0000002a95873000)
> libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95a51000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a95ba8000)
> libpthread.so.0 => /lib64/tls/libpthread.so.0
> (0x0000002a95cb3000)
> libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95dc8000)
> /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
> (0x0000002a95556000)
> We can see that lam-7.1.1/bin/mpicc is not dependent on the shared
> library libcr.so.
> Is this a bug of lam-7.1.1?
> Thank you for the reply, you may look at it after yuletime, happy
> your holidays!
>
> Xuezhao
> 2005-12-27
>
> ======= 2005-12-26 12:00:00 =======
>
>> From: Brian Barrett <brbarret_at_[hidden]>
>> To: General LAM/MPI mailing list <lam_at_[hidden]>
>> Subject: Re: LAM: Can't restart MPI applications after the LAM RTE
>> is reboot
>> Date: Sun25 Dec 2005 22:43:46 -0500
>>
>> Ah, it appears this is a bug in LAM 7.0.6 that has been fixed in LAM
>> 7.1.1. Is there any chance that you can upgrade to the latest
>> version of LAM?
>>
>> Brian
>>
>
>
> = = = = = = = = = = = = = = = = = = = =
>
>
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
