Summary: | sys-cluster/openmpi-1.4.1 blocks world | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | [OLD] Library | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | SebastianLuther |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Juergen Rose
2010-02-14 00:52:17 UTC
You can't install openmpi and mpich2 simultaneously (at least not without hacks). I think everything that requires mpich2 on your system could use openmpi, but some packges don't work with mpich2 (boost-1.39). If you really want to stay with mpich2 and you really need boost-1.39, then there is an ebuild for boost-1.39 that works with mpich2 in my overlay [1]. [1] http://github.com/few/few-s-gentoo-overlay In the last weeks I had several issues with openmpi, compare e.g. Bug 302056 and Bug 296518, which disappeared after removing openmpi and installing mpich2. So I did not actively try to install openmpi but it is installed as a dependency of octave-forge-octcdf: [nomerge ] sci-mathematics/octave-forge-octcdf-1.0.13 [2] [nomerge ] sci-libs/netcdf-4.0.1-r1 USE="cxx doc fortran hdf5 szip" [0] [nomerge ] sci-libs/hdf5-1.8.4-r2 USE="cxx examples fortran mpi szip threads zlib" [2] [nomerge ] virtual/mpi-2.0 USE="cxx fortran romio" [0] [ebuild N ] sys-cluster/openmpi-1.4.1 USE="cxx fortran ipv6 romio What should I do, mask openmpi and have perhaps difficulties with octave-forge-octcdf or mask mpich2, reemerge all mpi dependent packages (vtk, etc ) and have perhaps again the issues described in Bug 302056 and Bug 296518? At some computers I tried to remove mpich2 and to emerge world, which was successful. Then I remerged the directly mpi depending packages: root@condor:/(62)# for p in `equery -qC hasuse mpi` ; do emerge -v1 =$p ; done which was also successful. Then I tried to reemerge the packages which has mpi related issues: root@condor:/(63)# emerge -v1 netcdf octave gdal The first two packages also reemerge successful, but gdal fails with the error (Bug 296790): x86_64-pc-linux-gnu-g++ -Wl,-O1 gdalinfo.o -L/var/tmp/portage/sci-libs/gdal-1.6.2/work/gdal-1.6.2 -lgdal -L/usr/lib64 -lgeos_c -I/usr/include -lsqlite3 -lodbc -lodbcinst -L/usr/lib -lexpat -L/usr/lib -lxerces-c -lpthread -ljasper -lhdf5 -L/usr/lib64 -L/usr/lib64/lib -logdi31 -ljpeg -lgeotiff -ltiff -lpng -lnetcdf -lcfitsio -lpq -L/usr/lib64/postgresql-8.3/lib64 -lpq -lz -lpthread -lm -lrt -ldl -lcurl -lldap -lrt -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -march=nocona -O2 -pipe -fomit-frame-pointer -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -march=nocona -O2 -pipe -fomit-frame-pointer -g0 -Wno-system-headers -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lz -lgnutls -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib64 -lssl -lcrypto -o gdalinfo /var/tmp/portage/sci-libs/gdal-1.6.2/work/gdal-1.6.2/libgdal.so: undefined reference to `ompi_mpi_cxx_op_intercept' /var/tmp/portage/sci-libs/gdal-1.6.2/work/gdal-1.6.2/libgdal.so: undefined reference to `MPI::Datatype::Free()' /var/tmp/portage/sci-libs/gdal-1.6.2/work/gdal-1.6.2/libgdal.so: undefined reference to `MPI::Comm::Comm()' /var/tmp/portage/sci-libs/gdal-1.6.2/work/gdal-1.6.2/libgdal.so: undefined reference to `MPI::Win::Free()' collect2: ld returned 1 exit status This happens at least on two computers. Any hint is appreciated. (In reply to comment #2) > What should I do, mask openmpi and have perhaps difficulties with > octave-forge-octcdf or mask mpich2, reemerge all mpi dependent packages (vtk, > etc ) and have perhaps again the issues described in Bug 302056 and Bug 296518? That's up to you. Do what causes you less headache. ># emerge -v1 netcdf octave gdal >The first two packages also reemerge successful, but gdal fails with the error >(Bug 296790): [...] >This happens at least on two computers. Any hint is appreciated. bug 296790 comment 7 has a one line fix. Put the gdal ebuild in a local overlay and add the line on top of src_configure. (Or just wait for someone to fix the ebuild) If you have mpich2 installed, which satisfies the virtual, then there must be something hard-dep'd on openmpi when it should really depend on virtual/mpi instead. This may also be true for certain packages that still depend on mpich2 directly (but I can't think of any right now). It looks like vtk-5.4.2-r1 still uses the old combo-depend on the actual mpi packages, and openmpi is first in the list (which would be why it's being pulled in preference to mpich2). My recent experiences with openmpi vs mpich2 echo the posts here, in that I just had several build failures with packages related to openmpi, but everything works just fine with mpich2 (everything but boost apparently). IMHO, right now openmpi is broken, so whether it comes first in the virtual or first in a combo-depend, it still causes breakage either way. I just went through this argument recently over my fix for mpich2, and I couldn't convince the current package maintainers that unresolved symbols in mpi libs equals a broken library rather than a failure to use the mpi wrappers. The mpich2 upstream guys ended the argument for me by fixing their build setup (rendering my patch obsolete) but openmpi appears to have the exact same problem. Again, adding an "mpi wrapper" work-around to half a dozen packages does not fix the broken openmpi libs. Period. At some computers I removed mpich2 , followed bug 296790 comment 7, could install gdal, octave etc and I am satisfied. Thanks for the hints. I currently dont see any reason, why openmpi should be pulled in, when mpich2 is installed. The above emerge output suggests virutal/mpi, but it also accepts mpich2 as dependency. If this issue is still existing, please reopen this bug and add some informations about packages, which want mpich2 and which want openmpi |