severity 451193 serious
clone 451993 -1
reassign -1 libopenmpi-dev
retitle -1 libopenmpi-dev: /usr/lib/libmpi.so conflicts with other packages'
alternatives
merge 451991 451993
retitle 451993 gromacs-openmpi: build fails silently if libopenmpi-dev
installed before lam4-dev/libmpich1.0-dev
block 451991 by -1
thanks
On Mon, Nov 19, 2007 at 06:36:35PM +0100, Manuel Prinz wrote:
> gromacs-openmpi depends on lam4c2 which seems to be wrong. I think it's
> related to #451991 but I'm not sure, so I file it as a seperate bug. (I'm
> not sure about the severity either.)
As best I can tell, the problem here is that libopenmpi-dev ships
/usr/lib/libmpi.so as a file (symlink) in the package itself, while both
LAM (lam4c2, lam4-dev) and MPICH (libmpich1.0ldbl, libmpich1.0-dev) do
not have it in the file list, but *do* reference it as part of their
update-alternatives(1) configuration. As a result, depending on what
order the packages are installed in, you can end up with a symlink
pointing to a LAM or MPICH library, while dpkg still registers the
filename as belonging to OpenMPI. This in turn causes link errors
during compilation and improper dependencies from dpkg-shlibdeps.
As a demonstration, starting from a clean slate:
# aptitude purge libmpich1.0ldbl libmpich1.0-dev lam4c2 lam4-dev libopenmpi1
libopenmpi-dev
# aptitude install libopenmpi1 libopenmpi-dev
# aptitude install lam4c2 lam4-dev libmpich1.0ldbl libmpich1.0-dev
# ls -l /usr/lib/libmpi.so*
lrwxrwxrwx 1 root root 27 2007-11-19 18:54 /usr/lib/libmpi.so ->
/etc/alternatives/libmpi.so
lrwxrwxrwx 1 root root 15 2007-11-19 18:54 /usr/lib/libmpi.so.0 ->
libmpi.so.0.0.0
-rw-r--r-- 1 root root 513660 2007-10-06 06:06 /usr/lib/libmpi.so.0.0.0
Here, libmpi.so.0.0.0 is from libopenmpi1. The libmpi.so link is where
the problem arises:
# readlink -f /usr/lib/libmpi.so
/usr/lib/liblam.so.4.0
# dpkg -S /usr/lib/libmpi.so /usr/lib/liblam.so.4.0
libopenmpi-dev: /usr/lib/libmpi.so
lam4c2: /usr/lib/liblam.so.4.0
I've set the bug severity at serious because this is a filename overlap
between packages (Policy 10.1), which dpkg does not catch because
LAM/MPICH create the conflicting filename in their postinst scripts. If
OpenMPI is installed *after* the other two, builds work as expected, but
this can't be enforced on the buildds.
Both lam4-dev and libopenmpi-dev ship their equivalents to libmpi.so
under different original filenames and directories (/usr/lib/liblam.so
and /usr/lib/mpich/lib/shared/libmpich.so, respectively), underneath an
update-alternatives group using /usr/include/mpi as the master node. In
turn, binaries generally link against the original library path/filename
instead of /usr/lib/libmpi.so. OpenMPI does not do so - its
dependencies link against /usr/lib/libmpi.so directly, and it doesn't
share the same update-alternatives master node.
% mpicc.lam -showme
gcc -I/usr/lib/lam/include -pthread -L/usr/lib/lam/lib -llammpio -llamf77mpi
-lmpi -llam -lutil -ldl
^^^^^^^^^^^^^^^^^^ no equivalent with
mpicc.openmpi -showme
I think the solution is relocating OpenMPI's libmpi.so in a similar
manner to the other MPI packages, joining the same update-alternatives
scheme, and then recompiling its reverse dependencies. Does that sound
correct, or even reasonably possible?
--
Nicholas Breen
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
