All,<div><br></div><div>if openmpi is installed on sparc, it takes priority over lam ! (it has priority 40 and lam 30)</div><div><br></div><div>here is the result of  mpic++ -showme:compile           on <a href="http://smetana.debian.org">smetana.debian.org</a>                                                                                   </div>
<div><div>-I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -pthread</div><div>and link</div><div><div>mpic++ -showme:link                                                                                                </div>
<div>-pthread -L/usr/lib/openmpi/lib -lmpi_cxx -lmpi -lopen-rte -lopen-pal -ldl -Wl,--export-dynamic -lnsl -lutil -lm -ldl</div></div><div><br></div><div>so even though mpi-default-dev point to lam, if openmpi gets also installed it is in practice the default implementation</div>
<div>on sparc !</div><div><br></div><div>To my opinion this is a bug in the mpi system. Adam ? Others ?</div><div><br></div><div><div>There are 3 choices for the alternative mpi (providing /usr/include/mpi).</div><div><br>
</div><div>  Selection    Path                      Priority   Status</div><div>------------------------------------------------------------</div><div>* 0            /usr/lib/openmpi/include   40        auto mode</div><div>
  1            /usr/include/lam           30        manual mode</div><div>  2            /usr/lib/mpich/include     10        manual mode</div><div>  3            /usr/lib/openmpi/include   40        manual mode</div></div>
<div><br></div><br><div class="gmail_quote">On Wed, Jun 9, 2010 at 8:53 PM, Christophe Prud&#39;homme <span dir="ltr">&lt;<a href="mailto:prudhomm@debian.org">prudhomm@debian.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I tried, without success so far, to help cmake(FindMPI.cmake) find the proper mpi implementation.<div>It still finds openmpi which breaks linkage with boost::mpi<br><br></div><div>Best regards</div><div>C.<div><div></div>
<div class="h5"><br><div class="gmail_quote">
On Wed, Jun 9, 2010 at 12:08 PM, Adam C Powell IV <span dir="ltr">&lt;<a href="mailto:hazelsct@debian.org" target="_blank">hazelsct@debian.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Mon, 2010-06-07 at 02:25 -0500, Steve M. Robbins wrote:<br>
&gt; On Mon, Jun 07, 2010 at 09:02:41AM +0200, Christophe Prud&#39;homme wrote:<br>
&gt;<br>
&gt; &gt; On my side life depends solely on mpi-default-dev, it seems that some other<br>
&gt; &gt; package don&#39;t (e.g. hdf5), isn&#39;t it a problem ?<br>
&gt;<br>
&gt; Yes, something like that is likely the problem.<br>
&gt;<br>
&gt; Note that libhdf5-mpi-dev is supposed to alleviate that problem as it<br>
&gt; depends on the default MPI version.  Installing that package should<br>
&gt; not pull in any non-default MPI packages, IMHO.  Adam: any comment?<br>
<br>
</div>Indeed, that&#39;s the idea: Build-Depend on libhdf5-mpi-dev and<br>
mpi-default-dev and you should have a consistent MPI implementation<br>
across both.<br>
<br>
That said, the LAM HDF5 implementation seems to be missing a couple of<br>
libraries, such that for example PETSc doesn&#39;t build on architectures<br>
where LAM is the default.  I disabled PETSc HDF5 support on those<br>
arches, but haven&#39;t investigated further.<br>
<br>
-Adam<br>
<font color="#888888">--<br>
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6<br>
<br>
Engineering consulting with open source tools<br>
<a href="http://www.opennovation.com/" target="_blank">http://www.opennovation.com/</a><br>
</font></blockquote></div><br></div></div></div>
</blockquote></div><br></div>