[Debian-med-packaging] Bug#629815: Bug#630167: Bug#629815: No rule to make target `/usr/lib/libdl.so'
Modestas Vainius
modax at debian.org
Thu Jun 23 21:42:17 UTC 2011
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 <modax at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20110624/473a8462/attachment-0001.pgp>
More information about the Debian-med-packaging
mailing list