Bug#563705: MPI implementations in squeeze

[Alastair McKinstry]

>
> On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote:
>    
>> On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote:
>>      
>>>>> There is not much progress so far with respect to changing mpi-defaults
>>>>> to use MPICH2 instead of LAM on the architectures where Open MPI is not
>>>>> available yet. This needs a round of binNMUs. Marc Brockschmidt said he
>>>>> will look at the request to debian-release in the next few days, so this
>>>>> might resolve soon as well.
>>>>>            
>>>> Something to consider: this will break a lot of packages which use
>>>> FORTRAN until 563705 is fixed, and then that will require mods to
>>>> packages.
>>>>          
>>> I understand that bug as:
>>> if mpich2 or openmpi don't do the right thing when calling
>>> mpif77/mpif90, then symlinks are needed.
>>>
>>> Is there a proof that either of them doesn't do the right thing?
>>> Wouldn't it be more appropriate to fix them to do the right thing?
>>>
>>> (Those are honest questions -- I don't know anything about fortran)
>>>        
>> As discussed before (including in the bug), when there are mixed FORTRAN
>> and C++ symbols, it's not clear whether to use mpif77/90 or mpic++.
>>
>> Also, it's a big convenience: a lot of packages make multiple
>> executables and/or libraries, some of which use MPI and some don't.
>> Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib
>> directories seems easier than telling them to use mpicc and friends for
>> some targets and gcc for others.
>>      
> I'm not sure I buy that, since mpicc&  friends also hide include paths,
> which are not handled with alternatives currently. It sounds more like a
> way to break packages by getting them linked with the wrong version of
> MPI.
> Do you know of packages doing that already?
>
>    
Perhaps using pkg-config (an mpi.pc file) would be a better solution to 
this; it is more
standard: the mpicc, etc. approach isn't very scalable, you can't wrap 
every complex
library. Use mpi.pc to point to where  includes, etc. are, and 
alternatives to change
the mpi.pc between versions. You can then, if necessary, use 
dependencies and conflicts
within the pkg-config mechanism if need be, which aren't available if 
you use mixed
mpicc / gcc within Makefiles.

-- 
Alastair McKinstry  ,<alastair at sceal.ie>  ,<mckinstry at debian.org>     http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.