net/mpich2: libraries with many 'undefined symbols'

Rainer Hurling rhurlin at
Thu Feb 3 11:45:34 UTC 2011

Thanks for answering.

Am 02.02.2011 22:29 (UTC+1) schrieb Thierry Thomas:
> Le mer  2 fév 11 à 21:54:34 +0100, Rainer Hurling<rhurlin at>
>   écrivait :
>> Dear list,
> Hello,
>> since there is no maintainer for net/mpich2 I am writing directly to the
>> list. Hope this is ok.
>> I need MPICH2 for math/R (package Rmpi) and others (e.g. upcoming new
>> package math/sprng, PR 154249). Software using MPICH2 complains about
>> 'undefined symbols' like 'MPL_trfree'.
>> Looking into (after building net/mpich2), it shows many
>> undefined symbols (symbol names are stripped in installed version?):
>> nm work/mpich2-1.3/lib/ | grep " U "
>>                   U MPL_TrSetMaxMem
>>                   U MPL_env2bool
>>                   U MPL_env2int
>>                   U MPL_env2range
>>                   U MPL_env2str
>>                   U MPL_trDebugLevel
>>                   U MPL_trcalloc
>>                   U MPL_trdump
>>                   U MPL_trfree
>>                   U MPL_trid
>>                   ...
> 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 -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?

Why are there symbol names visible in libmpich.a, but not in Is this intended?

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

> Regards,

Thanks again,
Rainer Hurling

More information about the freebsd-ports mailing list