Bug#653616: libmpich2-dev: Missing library linkage for libmpich.so on MIPS(el) and S390

Wed Jan 11 18:26:39 UTC 2012

Hello Pavan,

Thanks for your replies.

There's one other issue here, which is that Debian has an "mpi-defaults"
system which sets up symbolic links from /usr/lib/libmpi.so to either
the openmpi or mpich2 library, depending on the platform.  That way, an
application can just use the mpi-default-dev package and link with -lmpi
to bring in the correct library for that platform.  (It also sets up a
symlink from /usr/include/mpi to the appropriate directory, so one can
use -I/usr/include/mpi as well.)  Since MPI implementations are supposed
to be source-compatible, it has worked well.

Until I think 12/7/2011, the default MPI implementations were either
OpenMPI or LAM, depending on the platform.  We switched from LAM to
MPICH2 because LAM is end-of-life and no longer maintained upstream.

But since we made that switch that switch in early December, MPICH2 has
been breaking a number of package builds now which used to work with
LAM, and some of those breakages have been because of this issu.

Let me ask this way: is a reason you do not want libmpich.so to link
with -lmpl?  libmpich uses libmpl's symbols, so one cannot use libmpich
without libmpl, so I don't see the harm in making such a link.

If I make a patch which links libmpich with libmpl, will you adopt it in
the Debian mpich2 package?

-Adam

On Wed, 2012-01-11 at 09:28 -0600, Pavan Balaji wrote:
> In that case, I'd suggest you explicitly list -lmpich, -lopa and -lmpl 
> in there for now.  You can always look at "mpicc -show" for any released 
> version to figure out what all flags/libs are being set.
> 
>   -- Pavan
> 
> On 01/07/2012 08:19 PM, Adam C Powell IV wrote:
> > That may be true, but it is a goal of Debian to be able to build the
> > archive using binutils-gold, which requires each ELF object (shared
> > library or executable) to link with every library whose symbol it uses.
> >
> > As I understand it, the reason is that binutils-gold allows for much
> > faster build-time and run-time linking than standard binutils.
> >
> > Feel free to ignore this, but at some point this will become a
> > release-critical bug.
> >
> > -Adam
> >
> > On Thu, 2011-12-29 at 23:44 -0600, Pavan Balaji wrote:
> >> The best method is to use pkg-config to find what libraries need to be
> >> linked in.  Currently, this list is libmpich, libmpl and libopa, if you
> >> are using generic TCP/IP and shared memory support.  But if you enable
> >> other modules, more libraries might be required.
> >>
> >>    -- Pavan
> >>
> >> On 12/29/2011 01:48 PM, Adam C Powell IV wrote:
> >>> X-DebBugs-CC: 653610 at bugs.debian.org
> >>> Package: libmpich2-dev
> >>> Version: 1.4.1-1+b1
> >>>
> >>> Greetings,
> >>>
> >>> On mips(el) and s390, the scalapack build fails with:
> >>>
> >>> gfortran  -o /build/buildd-scalapack_1.8.0-8-mipsel-D7TgwK/scalapack-1.8.0/TESTING/xspblas1tst psblas1tst.o psblastst.o slamch.o pblastst.o PB_Cwarn.o PB_Cabort.o -L /build/buildd-scalapack_1.8.0-8-mipsel-D7TgwK/scalapack-1.8.0 -lscalapack-mpich2 -lblacsF77init-mpich2 -lblacs-mpich2 -lblacsF77init-mpich2 -llapack -lblas -L/usr/lib/mpich2/lib/ -lmpich
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trfree'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_env2str'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trlevel'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trvalid'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trmalloc'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trspace'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_env2range'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trcalloc'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_env2int'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trdump'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_env2bool'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trstrdup'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trrealloc'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_TrSetMaxMem'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trinit'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trDebugLevel'
> >>> /usr/lib/mpich2/lib//libmpich.so: undefined reference to `MPL_trid'
> >>>
> >>> All of these symbols seem to be in libmpl.so, so linking libmpich2.so
> >>> with libmpl.so would fix this problem.
> >>>
> >>> You can see the error in at the end of the package build:
> >>>
> >>> dh_shlibdeps -plibmpich2-3
> >>> 	dpkg-shlibdeps -Tdebian/libmpich2-3.substvars debian/libmpich2-3/usr/lib/libmpich.so.3.2 debian/libmpich2-3/usr/lib/libmpichcxx.so.3.2 debian/libmpich2-3/usr/lib/libfmpich.so.3.2 debian/libmpich2-3/usr/lib/libmpl.so.1.1.0 debian/libmpich2-3/usr/lib/libmpichf90.so.3.2 debian/libmpich2-3/usr/lib/libopa.so.1.0.0
> >>> dpkg-shlibdeps: warning: symbol __cxa_pure_virtual used by debian/libmpich2-3/usr/lib/libmpichcxx.so.3.2 found in none of the libraries.
> >>> [and 9 more missing symbols]
> >>> dpkg-shlibdeps: warning: symbol MPL_trdump used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_TrSetMaxMem used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_putenv used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_env2range used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trrealloc used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trlevel used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trDebugLevel used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trinit used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trcalloc used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: symbol MPL_trfree used by debian/libmpich2-3/usr/lib/libmpich.so.3.2 found in none of the libraries.
> >>> dpkg-shlibdeps: warning: 8 other similar warnings have been skipped (use -v to see them all).
> >>>
> >>> It's interesting that this works fine on other platforms, that it either
> >>> ignores or manages to find libmpl...  But in general, it's best to link
> >>> to all of the libraries whose symbols you use, I'm pretty sure it's also
> >>> a requirement of binutils-gold.
> >>>
> >>> Thanks,
> >>> Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120111/1d89155d/attachment.pgp>