sci-visualization/paraview-3.2.1 with USE="doc hdf5 mpi* python qt4 threads -examples" failed to build, see log file. I think the real error occur here: Linking CXX shared library ../../../bin/libXdmf.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmpich.a(send.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libmpich.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [bin/libXdmf.so] Error 1 make[1]: *** [Utilities/Xdmf2/libsrc/CMakeFiles/Xdmf.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... It seems to be a problem with the mpich lib. Reproducible: Always
Created attachment 143918 [details] The log file
So what's up with the missing shared library for sys-cluster/mpich? Ditto Bug 176849 and Bug 202684?
sci-visualization/paraview depends sys-cluster/mpich and not on virtual/mpi nor || (sys-cluster/mpich sys-cluster/mpich2). And sys-cluster/mpich doesn't install a libmich.so and the libmich.a isn't build with -fPIC compiler flag. And to do USE=-mpi is not an option. And in detail, I don't know why there is no libmich.so build.
Personally, I much rather try enabling support for openmpi in paraview (if possible) instead of spending time fixing the now almost 3 year old mpich. Would this be an acceptable option for you? I've done this in the past for vtk and lam-mpi which is now deprecated in favour of openmpi. Thanks, Markus
If openmpi will work, that would be the perfect option! Oliver
(In reply to comment #4) > Personally, I much rather try enabling support for openmpi > in paraview (if possible) instead of spending time fixing the now > almost 3 year old mpich. Sounds great, ditto for the other two packages mentioned in Comment #2 ;)
I just committed a patch that should allow paraview to compile against openmpi and mpich2. Please let me know if this works for you as well. Thanks, Markus
Thanks for that patch. Now I can compile against the openmpi lib. And with the mpi useflag the volume rendering works! So I will close this bug. Oliver
Great and thanks for testing! I'll apply the same set of patches to vtk as well then. Markus
Just a small question why not changing the dep to virtual/mpi. As long as mpich is in the tree it could be used even if it is old and outdated. As far as i know paraview should work with every mpi implementation which is currently in gentoo. This should apply to vtk too, at least for mpich2, openmpi and lam-mpi according to the ebuild. I think this is a conflict with the virtual itself as it is listing mpich as the first value so the old and outdated implementation will be used first if none is present! Why not use something like this in the virtual: RDEPEND="|| ( sys-cluster/openmpi sys-cluster/mpich2 sys-cluster/lam-mpi sys-cluster/mpich )"
(In reply to comment #10) > Just a small question why not changing the dep to virtual/mpi. > > As long as mpich is in the tree it could be used even if it is old and > outdated. As far as i know paraview should work with every mpi implementation > which is currently in gentoo. This should apply to vtk too, at least for > mpich2, openmpi and lam-mpi according to the ebuild. Unfortunately, this is not the case. mpich only provides static libs and hence paraview can't link against it on any arch that needs pic code such as amd64. > > I think this is a conflict with the virtual itself as it is listing mpich as > the first value so the old and outdated implementation will be used first if > none is present! Why not use something like this in the virtual: > > RDEPEND="|| ( > sys-cluster/openmpi > sys-cluster/mpich2 > sys-cluster/lam-mpi > sys-cluster/mpich > )" > This is currently in the works by the cluster herd but requires that a stable version of openmpi is available on most arches, which takes some time. Best, Markus
