Date: Thu, 03 Feb 2011 14:19:16 +0100 From: Rainer Hurling <rhurlin@gwdg.de> To: thierry@FreeBSD.org Cc: freebsd-ports@freebsd.org Subject: Re: net/mpich2: libraries with many 'undefined symbols' Message-ID: <4D4AAB54.9030001@gwdg.de> In-Reply-To: <20110203133557.33003e7j1xacsls0@graf.pompo.net> References: <4D49C48A.7080604@gwdg.de> <20110202212907.GC29365@graf.pompo.net> <4D4A9559.2010502@gwdg.de> <20110203133557.33003e7j1xacsls0@graf.pompo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 03.02.2011 13:35 (UTC+1) schrieb thierry@FreeBSD.org:
> Selon Rainer Hurling <rhurlin@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D4AAB54.9030001>