close 630167 2.8.4+dfsg.1-5 thanks Hello,
On ketvirtadienis 23 Birželis 2011 14:20:59 Andreas Tille wrote: > I tried to rebuild gofigure2 (which is affected by #629815) now I do > not get the > > No rule to make target `/usr/lib/libdl.so', needed by > `lib/libvtkRenderingAddOn2.so.0.8' > > any more but rather > > No rule to make target `/usr/lib/libXt.so', needed by > `lib/libPoissonReconstruction.so.0.8' $ grep -rn -e '/usr/lib/libXt.so' /usr/lib/vtk-5.6/ /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:76: SET("vtkRendering_LIB_DEPENDS" "general;vtkGraphics;general;vtkImaging;general;vtkIO;general;vtkftgl;general;QtGui;general;QtCore;general;/usr/lib/libgl2ps.so;general;/usr/lib/libz.so;general;/usr/lib/libpng.so;general;/usr/lib/libz.so;general;/usr/lib/libGL.so;general;/usr/lib/libXt.so;general;X11;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:186: SET("vtkRendering_LIB_DEPENDS" "vtkGraphics;vtkImaging;vtkIO;vtkftgl;QtGui;QtCore;/usr/lib/libgl2ps.so;/usr/lib/libz.so;/usr/lib/libpng.so;/usr/lib/libz.so;/usr/lib/libGL.so;/usr/lib/libXt.so;X11;") $ grep -rn -e '/usr/lib/libdl.so' /usr/lib/vtk-5.6/ /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:5: SET("Cosmo_LIB_DEPENDS" "general;vtksys;general;vtkCommon;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen- rte.so;general;/usr/lib/openmpi/lib/libopen- pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:6: SET("MapReduceMPI_LIB_DEPENDS" "general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen- rte.so;general;/usr/lib/openmpi/lib/libopen- pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:9: SET("VPIC_LIB_DEPENDS" "general;vtksys;general;/usr/lib/openmpi/lib/libmpi_cxx.so;general;/usr/lib/openmpi/lib/libmpi.so;general;/usr/lib/openmpi/lib/libopen- rte.so;general;/usr/lib/openmpi/lib/libopen- pal.so;general;/usr/lib/libdl.so;general;/usr/lib/libnsl.so;general;/usr/lib/libutil.so;general;/usr/lib/libm.so;general;/usr/lib/libdl.so;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:115: SET("Cosmo_LIB_DEPENDS" "vtksys;vtkCommon;/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen- rte.so;/usr/lib/openmpi/lib/libopen- pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:116: SET("MapReduceMPI_LIB_DEPENDS" "/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen- rte.so;/usr/lib/openmpi/lib/libopen- pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;") /usr/lib/vtk-5.6/VTKLibraryDepends.cmake:119: SET("VPIC_LIB_DEPENDS" "vtksys;/usr/lib/openmpi/lib/libmpi_cxx.so;/usr/lib/openmpi/lib/libmpi.so;/usr/lib/openmpi/lib/libopen- rte.so;/usr/lib/openmpi/lib/libopen- pal.so;/usr/lib/libdl.so;/usr/lib/libnsl.so;/usr/lib/libutil.so;/usr/lib/libm.so;/usr/lib/libdl.so;") $ dpkg -S VTKLibraryDepends.cmake libvtk5-dev: /usr/lib/vtk-5.6/VTKLibraryDepends.cmake $ dpkg -l libvtk5-dev | grep ii ii libvtk5-dev 5.6.1-6 VTK header files for building C++ code So you can reassign your bug where it belongs (libvtk5-dev). Unfortunately, VTK has one of the most hackish (and outdated in places) cmake code. Good luck fixing it. > and thus I assume my action to reopen #630167 (which is unfortunately > not properly documented in the bug log) was not the right thing to do. Yes, it was not the right thing to do because: 1) the bug is not related to your problem. It was about kfreebsd and armel while your package fails on all arches. 2) I had no clue what happened because original explanation didn't say much at all. I have no idea how you managed to reopen it in such a cryptic way. > Similarly I can confirm that when trying to build ginkgocadx I do not > run any more in the missing libdl.so but rather into > > No rule to make target `/lib/libwrap.so.0', needed by > `src/cadxcore/libCADxCore.so.2.4.1.1' > > which somehow smells like libwrap0 is guilty for the problem. I admit > that this multiarch stuff is above my horizon and I hope that somebody > might be able to clarify what might be the correct way of action now. Always grep the source before blaming something else :-) $ grep -rn '/lib/libwrap.so.0' . ./src/cadxcore/CMakeLists.txt:171: TARGET_LINK_LIBRARIES(${PROJECT_NAME} dcmdsig oflog /lib/libwrap.so.0) -- Modestas Vainius <mo...@debian.org>
signature.asc
Description: This is a digitally signed message part.