Valter Dal Bo wrote:
> Hi !
>
> Thank you for your answer.
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: LAM: RHEL4 and lam 7.0.6 problem
>> From:
>> Tim Prince <timothyprince_at_[hidden]>
>> Date:
>> Wed, 17 May 2006 08:48:15 -0700
>> To:
>> General LAM/MPI mailing list <lam_at_[hidden]>
>>
>> To:
>> General LAM/MPI mailing list <lam_at_[hidden]>
>>
>>
>> Valter Dal Bo wrote:
>>> Hi all !
>>>
>>> Maybe someone can help me with this issue.
>>>
>>> I have a problem with lam-mpi using RHEL4 with lam v.7.0.6 that did not
>>> occour on Redhat9 with lam
>>> v.6.5.9.
>> You can't mix an application built for lam-6.5 with lam-7.0. I think
>> LSTC
>> prefers to support lam-7.0.3 (built with --enable-shared etc) or Intel or
>> HP MPI for the x86-64 systems. In most cases, you have to rebuild lam
>> yourself,
>> using the same version as your application expects, including matching
>> --enable-shared or non-shared, and matching 32- or 64-bit compilers.
>> As you appear to be using a version built with the ifort fce/8.1
>> compiler, that may enter into your consideration. You should be able
>> to build lam with gcc/g77 or gcc/gfortran if you aren't relinking your
>> application. I think you can see how lam support has become more
>> difficult on 32/64-bit systems.
>>
>>
>
> Strangely enough, I thought that an application built for a lower
> version would have run on a higher version.
> Thing is, I have a few different applications, and DYNA is only one of
> them, that all should run with different LAM versions.
> If what you just said is right, I am never gonna be able to run them all
> on the same machine.
> Again, seeing that I have RHEL licenced and subscribed, I wouldn't mind
> trying to keep the system as "clean" as possible so that I can manage it
> via RHN.
You could have found out about the total lack of compatibility between
major lam versions by checking the mailing list archive.
I think you've already seen the following responses from others;
Everyone who runs multiple applications with lam probably has multiple
lam versions installed, not to mention other MPI families, all with the
potential to break each other if mixed up; for example
/usr/local/lam659_32,/usr/local/lam703_64 ..
and the simple minded way is simply to set PATH=/usr/local/lam703_64/bin
LD_LIBRARY_PATH=/usr/local/lam703_64/lib
wipe ;lamboot
Not too difficult on 1 or 2 nodes, but more automation is worth while on
a real cluster.
Given that the RH supplied versions of lam tend to be way out of date
and not built with --enable-shared, they aren't necessarily of much use.
|
