[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