Created attachment 297797 [details] patch for configure.in to resolve missing references found in mpi_cxx library Ebuilds for both 1.6.3-r1 and 1.8.1-r1 fail with the following error messages: var/tmp/portage/sci-libs/gdal-1.8.1-r1/work/gdal-1.8.1/libgdal.so: undefined reference to `ompi_mpi_cxx_op_intercept' /var/tmp/portage/sci-libs/gdal-1.8.1-r1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Datatype::Free()' /var/tmp/portage/sci-libs/gdal-1.8.1-r1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Comm::Comm()' /var/tmp/portage/sci-libs/gdal-1.8.1-r1/work/gdal-1.8.1/libgdal.so: undefined reference to `MPI::Win::Free()' A quick search provided the following troubleshooting reference: http://www.cs.utah.edu/formal_verification/GEM/help/troubleshooting.html A quick hack to atoconfig adding 'LPIB="-lmpi_cxx $LIBS"' to the end of autoconfig.in solved the problem (see attached mpi.patch) It is likely that this is not a full and proper fix, as we should probably track down if MPI is a required package or optional, or if it a problem with the IUSE="cxx". In either case, the MPI C++ library references are missing. Hope that helps...
Created attachment 297799 [details] emerge --info output
With what useflags did you compile the gdal please.
*** Bug 417603 has been marked as a duplicate of this bug. ***
You guys need to find out which package pull in the mpi and then fix its pkgconfig, becuase it should provide the -lmpi_cxx. The gdal itself do ot require these symbols at all, as they are not used anywhere in its source. Also interesting would be try to alter the configure phase and change --without-libtool to --with-libtool, maybe they fixed it and it should solve this problem too.
(In reply to comment #4) > You guys need to find out which package pull in the mpi and then fix its > pkgconfig, becuase it should provide the -lmpi_cxx. The gdal itself do ot > require these symbols at all, as they are not used anywhere in its source. > > Also interesting would be try to alter the configure phase and change > --without-libtool to --with-libtool, maybe they fixed it and it should solve > this problem too. I was hoping to get to this, but things are piling up at work and I realistically will not get back to this for months. Can anyone else follow up on this?
one thing that does come to mind though is if the mpi use flag is set then for now it would be appropriate to include the patch until it is fixed upstream. This would keep things from breaking now, and allow us to work on fixing it correctly.
I'm still hammered at work, but I just tested the latest ebuild <gdal-1.9.1>, and the problem still persists. As a quick test I pulled in the old mpi patch from before and it works just fine. I'm still not sure what is pulling in MPI. EBo --
(In reply to John (EBo) David from comment #7) > I'm still hammered at work, but I just tested the latest ebuild > <gdal-1.9.1>, and the problem still persists. As a quick test I pulled in > the old mpi patch from before and it works just fine. > > I'm still not sure what is pulling in MPI. > > EBo -- Does it persist in gdal-1.10.0-r1?
(In reply to Aaron W. Swenson from comment #8) > Does it persist in gdal-1.10.0-r1? I just built gdal-1.10.0-r1 without incident, so I am updating the status to works for me -- or at least so far. This was built but not fully tested on an amd64. I will try the x86 later to verify. As a note, I have been using a hacked 1.10.0 ebuild since May 15'th with good results. Thanks!
