# emerge -v mayavi These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] sci-libs/vtk-5.0.3 USE="doc java mpi python qt3 qt4 tcl threads tk -examples -patented" 8,130 kB [ebuild N ] sci-visualization/mayavi-1.5 USE="doc -examples" 514 kB Total: 2 packages (2 new), Size of downloads: 8,643 kB .... [ 75%] Building CXX object Parallel/CMakeFiles/vtkParallel.dir/vtkParallelInstantiator.o Linking CXX shared library ../bin/libvtkParallel.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libmpich.a(isend.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/libvtkParallel.so.5.0.3] Error 1 make[1]: *** [Parallel/CMakeFiles/vtkParallel.dir/all] Error 2 make: *** [all] Error 2
Created attachment 117991 [details] emerge --info
Hi Vladimir, Thanks for your bug report. It looks like vtk links against /usr/lib64/libmpich.a to generate libvtkParallel.so which is of course bound to fail! I'll have a look at. Thanks, Markus
Ok, it looks like sys-cluster/mpich doesn't build a shared library and unfortunately virtual/mpi pulls in mpich. Hence, could you please replace sys-cluster/mpich on your system by sys-cluster/lam-mpi which does provide a *.so and see if that works. If so, we'll probably have to replace the virtual/mpi in the ebuild with lam-mpi and whatever other mpi implementations work. Thanks, Markus
(In reply to comment #3) > Ok, it looks like sys-cluster/mpich doesn't build a shared > library and unfortunately virtual/mpi pulls in mpich. > > Hence, could you please replace sys-cluster/mpich on > your system by sys-cluster/lam-mpi which does provide > a *.so and see if that works. If so, we'll probably have > to replace the virtual/mpi in the ebuild with lam-mpi > and whatever other mpi implementations work. I'd rather you didn't do that, we can just -fPIC the library instead.
Hi Donnie, If that's easily possible that would be great! Unfortunately, I don't know mpich at all and what is needed to achieve this. Please advise. Best, Markus
I did a little more digging and it turns out that cmake currently only "knows" about mpich and mpich2. Hence, building vtk against lam-mpi fails during linking. I'll have to have a closer look at this. Markus
(In reply to comment #5) > If that's easily possible that would be great! Unfortunately, > I don't know mpich at all and what is needed to achieve this. > Please advise. I don't recall the mpich build system being all that complex. Should just be a matter of tagging -fPIC into libmpich_la_CFLAGS in whatever Makefile.am that's in (I think it's autotools).
Looks similar to this bug: 126774 . After building the library with -fPIC for a while (it is a bad thing to do this for the whole system), I fell back to USE=-mpi for VTK.
(In reply to comment #8) > Looks similar to this bug: 126774 . After building the library with -fPIC for a > while (it is a bad thing to do this for the whole system), I fell back to > USE=-mpi for VTK. > Yeah! BTW, I think I managed to fix VTK's cmake files and it should now build properly against lam-mpi; it does so for me at least! If you have some time to test it I'd appreciate it. @Donnie: I am not sure if I understood your comment #7 properly. Are you suggesting to switch mpich from its present static libs to all shared or rather libtoolizing it and providing both? Thanks, Markus
Sorry for the delay in fixing this. I've now completely removed mpich support from vtk and added support for openmpi, lam-mpi, and mpich2 instead. All three MPI implementations should work fine, with openmpi being my (personal) favourite :) Best, Markus
