net/mpich2: libraries with many 'undefined symbols'

thierry at thierry at
Thu Feb 3 12:57:08 UTC 2011

Selon Rainer Hurling <rhurlin at> 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}"


> 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  
> 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.

Th. Thomas.

More information about the freebsd-ports mailing list