Summary: | sci-libs/gdal-1.6.3-r1 fails to emerge with openmpi | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | [OLD] Library | Assignee: | Steve Arnold <nerdboy> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | sci-geosciences, zeekec |
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | /var/tmp/portage/sci-libs/gdal-1.6.3-r1/temp/build.log |
Description
Juergen Rose
2010-03-22 14:29:16 UTC
Created attachment 224677 [details]
/var/tmp/portage/sci-libs/gdal-1.6.3-r1/temp/build.log
Adding use hdf5 && has_version sci-libs/hdf5[mpi] && export CC=mpicc CXX=mpicxx as first line of pkg_setup() solves the problem for me. The same problem occurs earlier with gdal-1.6.?. It would be good if the patch could go into the tree. gdal is not broken; as shown in Bug# 302621 comment #10, the openmpi Fortran 90 library is broken, which implies several possible work-arounds, depending on your requirements: 1) unmerge openmpi and install mpich2 2) get the openmpi maintainers to fix their broken libmpi_f90 3) disable f90 support and rebuild openmpi The first two provide complete functionality, while the 3rd one is a little less optimal since you would lose f90 mpi support. What I don't see as an acceptable work-around is to patch several packages with questionable kluges just to avoid fixing a broken library. I just don't see why the "kluge several non-broken packages" approach is preferable to making a single fix. Hi Steve, I had installed mpich2 in the past, but then the installation of openmpi was required by boost-1.42, octave(?) or octave-forge(?). And mpich2 and openmpi blocks each other. I got the recommendation to remove the old mpich2 and install the new openmpi, see also Bug 305005. So I did not know, if solution 1 of Comment #3 is very good for me. Nevertheless I tried. I removed openmpi. Emerged again mpich2. Did 'lafilefixer --justfixit', reemerged all mpi dependent packages: for p in `equery -qC hasuse mpi`; do emerge -v1 =$p; if [ $? != 0 ]; then exit 1; fi; done Then I tried to repair broken library dependencies with revdep-rebuild, which fails, because boost-1.39.0 depends on openmpi. I erase boost-1.39.0 and boost-build-1.39.0, and tried again revdep-rebuild: * All prepared. Starting rebuild emerge --oneshot dev-java/hdf-java:0 dev-lang/gdl:0 media-gfx/hugin:0 sci-geosciences/mapnik:0 sci-libs/netcdf:0 sci-visualization/paraview:0 .......... Calculating dependencies... done! [ebuild NS ] dev-util/boost-build-1.39.0 [1.42.0] USE="examples python" [ebuild R ] sci-libs/netcdf-4.0.1-r1 [ebuild R ] media-gfx/hugin-2010.0.0 [ebuild R ] dev-java/hdf-java-2.6.1 [ebuild R ] dev-lang/gdl-0.9_rc4 [ebuild N ] sys-cluster/openmpi-1.4.1 USE="cxx fortran ipv6 romio threads -debug -heterogeneous -infiniband -mpi-threads -pbs -vt" [ebuild NS ] dev-libs/boost-1.39.0 [1.42.0] USE="doc eselect expat icu mpi python tools -debug -test" [ebuild R ] sci-visualization/paraview-3.6.2 [ebuild U ] sci-geosciences/mapnik-0.6.1-r3 [0.6.1-r2] [blocks B ] sys-cluster/openmpi ("sys-cluster/openmpi" is blocking sys-cluster/mpich2-1.2.1_p1) [blocks B ] sys-cluster/mpich2 ("sys-cluster/mpich2" is blocking sys-cluster/openmpi-1.4.1) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. ('installed', '/', 'sys-cluster/mpich2-1.2.1_p1', 'nomerge') pulled in by sys-cluster/mpich2 required by world ('ebuild', '/', 'sys-cluster/openmpi-1.4.1', 'merge') pulled in by sys-cluster/openmpi required by ('ebuild', '/', 'sci-visualization/paraview-3.6.2', 'merge') >=sys-cluster/openmpi-1.2.9[cxx] required by ('ebuild', '/', 'dev-libs/boost-1.39.0', 'merge') It looks for me, if mapnik requires boost-1.39.0, which requires openmpi, which is blocked by mpich2. So solution 1 of comment #3 seems not to work for me. I suppose that solution 2 of comment #3 also not works for me, because my influence of openmpi developer is not large enough. With solution 3 of comment #3 I have the problem, that there is no f90 flag of openmpi, so I don't know how to disable f90 support in openmpi: root@orca:/root(47)# emerge -pvD openmpi These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sys-cluster/openmpi-1.4.1 USE="cxx fortran ipv6 romio threads -debug -heterogeneous -infiniband -mpi-threads -pbs -vt" 0 kB [1] So for me remains only the solution to patch privately every version of gdal with: use hdf5 && has_version sci-libs/hdf5[mpi] && export CC=mpicc CXX=mpicxx as first line of pkg_setup() Regards Juergen More than year later I get the same issue with sci-libs/gdal-1.8.1 and sys-cluster/openmpi-1.5.3-r2 I still get the same error. 'emerge gdal' fails with: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fPIC -Wall -Wdeclaration-after-statement -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/port -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/gcore -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/alg -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/ogr -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/ogr/ogrsf_frmts -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/frmts -DOGR_ENABLED -I/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/port -Iexternal/include -I/usr/ -I/usr//include -c -o gdalinfo.o gdalinfo.c x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed gdalinfo.o -L/var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1 -lgdal -lpoppler -L/usr/lib64 -lgeos_c -L/usr/lib -lsqlite3 -lodbc -lodbcinst -lexpat -ljasper -lhdf5 -L/usr -L/usr/lib -logdi -lgif -ljpeg -Lexternal/lib -lgeotiff -Lexternal/lib -ltiff -lpng -lnetcdf -lcfitsio -L/usr/lib64/postgresql-9.0/lib64 -lpq -lz -L/usr/ -L/usr//lib -lpthread -lm -lrt -ldl -lcurl -lgcrypt -lldap -lrt -L/usr/lib64 -march=native -O2 -pipe -g0 -Wno-system-headers -Wl,-O1 -Wl,--as-needed -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkeyutils -lresolv -ldl -lz -lgnutls -Wl,-O1 -Wl,--as-needed -L/usr/lib64 -lmysqlclient -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto -o gdalinfo /var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/libgdal.so: undefined reference to `ompi_mpi_cxx_op_intercept' /var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Datatype::Free()' /var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Comm::Comm()' /var/tmp/portage/sci-libs/gdal-1.8.1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Win::Free()' I solve this issue since one year by patching every version of new gdal ebuild by inserting: use hdf5 && has_version sci-libs/hdf5[mpi] && export CC=mpicc CXX=mpicxx into pkg_setup() If the reason is, as Steve emphasized in Comment 3, the broken libmpi_f90, how can we convince the openmpi maintainers to fix their libraries? And again almost one year later now with gdal-1.9.1 and openmpi-1.5.5 I get the same error: x86_64-pc-linux-gnu-gcc -march=amdfam10 -O2 -pipe -fPIC -Wall -Wdeclaration-after-statement -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/port -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/gcore -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/alg -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/ogr -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/ogr/ogrsf_frmts -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/frmts -DOGR_ENABLED -I/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/port -I/usr/include -Iexternal/include -I/usr/ -I/usr//include -c -o gdalinfo.o gdalinfo.c x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed gdalinfo.o -L/var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1 -lgdal -lpoppler -L/usr/lib64 -lgeos_c -L/usr/lib -lsqlite3 -lodbc -lodbcinst -lexpat -lxerces-c -lpthread -ljasper -L/usr/lib -lnetcdf -lhdf5 -L/usr -L/usr/lib -logdi -lgif -ljpeg -Lexternal/lib -lgeotiff -Lexternal/lib -ltiff -lpng -lcfitsio -L/usr/lib64/postgresql-9.1/lib64 -lpq -lz -L/usr/ -L/usr//lib -lpthread -lm -lrt -ldl -lcurl -lldap -lrt -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lz -lssl3 -lsmime3 -lnssutil3 -lnss3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -Wl,-O1 -Wl,--as-needed -L/usr/lib64/mysql -lmysqlclient -L/usr//lib64 -lz -lcrypt -lnsl -lm -L/usr/lib64/ -lssl -lcrypto -o gdalinfo /var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/libgdal.so: undefined reference to `ompi_mpi_cxx_op_intercept' /var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/libgdal.so: undefined reference to `MPI::Win::Free()' /var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/libgdal.so: undefined reference to `MPI::Datatype::Free()' /var/tmp/portage/sci-libs/gdal-1.9.1/work/gdal-1.9.1/libgdal.so: undefined reference to `MPI::Comm::Comm()' And again as before inserting a line: use hdf5 && has_version sci-libs/hdf5[mpi] && export CC=mpicc CXX=mpicxx at the begin pkg_setup() solved the issue. |