net/mpich2: libraries with many 'undefined symbols'

[Rainer Hurling]

Am 03.02.2011 13:35 (UTC+1) schrieb thierry at FreeBSD.org:
> Selon Rainer Hurling <rhurlin at gwdg.de> le jeu 3 fév 12:45:29 2011 :
>
>>> These symbols belong to libmpl:
>>>
>>> nm -A /usr/local/lib/libmpl.a | grep MPL_
>>>
>>> So you have to link with -lmpl (and maybe with -lopa too).
>>
>> I think I do understand this for software which uses MPICH2.
>>
>> With your suggestion I am able to build math/R package 'Rmpi' without
>> errors any more and to install it. For this I only had to extend the
>> configure script of the R package:
>>
>> -PKG_LIBS="-L${MPI_LIBPATH} -lmpich ${MPI_LIBS}"
>> +PKG_LIBS="-L${MPI_LIBPATH} -lmpich -lmpl -lopa ${MPI_LIBS}"
>
> Great!
>
>> Sorry for my ignorance:
>> Is it ok to have symbols like MPL_trfree, MPI_F_STATUS_IGNORE and
>> others 'undefined' within libmpich?
>
> I think so: this is a design choice (by the authors).
>
>> Why are there symbol names visible in libmpich.a, but not in
>> libmpich.so.2.0? Is this intended?
>
> No, the static libraries and the shared ones are identical. If you link
> statically, you also need libmpl.a

Ok, so I usually have to take care to link libraries like libmpl, libopa 
etc. in addition to libmpich (or using the wrappers if possible).

>>> Another solution could be to link with mpicc and friends instead of
>>> gcc/g++/gfortran, as these wrappers set the correct flags and link to
>>> the correct libraries as required.
>>
>> Yes. I know of mpicc, mpic++, mpicxx and others. I tried to use them
>> in my experimental port math/sprng, but it seems a little bit tricky.
>>
>>> Yet another solution could be to configure mpich2 with
>>> --enable-lib-depend, but this is experimental...

What would be the consequence of configuring mpich2 with 
--enable-lib-depend? Would dependencies like libmpl be more integrated 
in libmpich?

>>> BTW, a new version has been released, and I have plan to upgrade it
>>> after the ports thaw.
>>
>> Nice, looking forward to it.
>
> The new release installs more pkgconfig (.pc) files, thus it should
> become easier to guess the correct flags and libs.
>
> Regards,

Thanks again for your answers. They are very helpful to me.
Rainer Hurling