net/mpich2: libraries with many 'undefined symbols'

thierry at FreeBSD.org thierry at FreeBSD.org
Thu Feb 3 12:57:08 UTC 2011


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

>> 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...
>>
>> 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,
-- 
Th. Thomas.


More information about the freebsd-ports mailing list