Bug#629815: Bug#630167: Bug#629815: No rule to make target `/usr/lib/libdl.so'
On Fri, Jun 24, 2011 at 12:42:17AM +0300, Modestas Vainius wrote: close 630167 2.8.4+dfsg.1-5 thanks At first: Sorry for the confusion. ... $ dpkg -S VTKLibraryDepends.cmake libvtk5-dev: /usr/lib/vtk-5.6/VTKLibraryDepends.cmake $ dpkg -l libvtk5-dev | grep ii ii libvtk5-dev5.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. Thanks for your analysis. I have just no idea of cmake and obviosely had no idea where to look at after I have seen that old cmake in testing worked and cmake in unstable did not. The hint about multiarch stuff added in unstable seemed like a reasonable explanation at first sight. So thanks for enlighting the reasons. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: Bug#630167: Bug#629815: No rule to make target `/usr/lib/libdl.so'
On Fri, Jun 24, 2011 at 8:11 AM, Andreas Tille ti...@debian.org wrote: 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. Thanks for your analysis. I have just no idea of cmake and obviosely had no idea where to look at after I have seen that old cmake in testing worked and cmake in unstable did not. The hint about multiarch stuff added in unstable seemed like a reasonable explanation at first sight. So thanks for enlighting the reasons. Thanks Modestas for finding the reason. I started a long time ago fixing VTK to remove the culprit call to EXPORT_LIBRARY_DEPENDENCIES, but had to give up. I could not get it apply upstream, maybe we can resurect this patch in debian/VTK: https://github.com/malaterre/VTK/commit/07db5b4fd2477f3843e6726ea5011aa2540921ab 2cts -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: Fixing libvtk build process (Was: Bug#629815: No rule to make target `/usr/lib/libdl.so')
On Fri, Jun 24, 2011 at 10:20:32AM +0200, Sebastian Hilbert wrote: Thanks Modestas for finding the reason. I started a long time ago fixing VTK to remove the culprit call to EXPORT_LIBRARY_DEPENDENCIES, but had to give up. I could not get it apply upstream, maybe we can resurect this patch in debian/VTK: https://github.com/malaterre/VTK/commit/07db5b4fd2477f3843e6726ea5011aa2540 921ab If it fixes the problem we should. Upstream knows best which patches will cause trouble but if there is no agreement with upstream and there is a serious issue I vote for patching at the packaging level. I'd even vote for making it soonish because it affects two of our packages drastically - one of them (ginkgocadx) is highly wanted an will not make any progress without fixing this problem. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: Fixing libvtk build process (Was: Bug#629815: No rule to make target `/usr/lib/libdl.so')
Am Freitag, 24. Juni 2011, 10:57:16 schrieb Andreas Tille: On Fri, Jun 24, 2011 at 10:20:32AM +0200, Sebastian Hilbert wrote: Thanks Modestas for finding the reason. I started a long time ago fixing VTK to remove the culprit call to EXPORT_LIBRARY_DEPENDENCIES, but had to give up. I could not get it apply upstream, maybe we can resurect this patch in debian/VTK: https://github.com/malaterre/VTK/commit/07db5b4fd2477f3843e6726ea5011aa 2540 921ab If it fixes the problem we should. Upstream knows best which patches will cause trouble but if there is no agreement with upstream and there is a serious issue I vote for patching at the packaging level. I'd even vote for making it soonish because it affects two of our packages drastically - one of them (ginkgocadx) is highly wanted an will not make any progress without fixing this problem. If anyone is willing tp provide test packages (e.g. patched packages) I volutueer to test them in my system. Regards, Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: No rule to make target `/usr/lib/libdl.so'
Hi again, to give an update to this problem: On Fri, Jun 10, 2011 at 11:37:00AM +0200, Mathieu Malaterre wrote: On Thu, Jun 9, 2011 at 11:27 PM, Andreas Tille andr...@an3as.eu wrote: On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote: The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in incoming. It has a different multiarch implementation. $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-4_amd64.deb) ... I: new cache content cmake_2.8.4+dfsg.1-4_amd64.deb added No change. :-(( Any further hint? I think the issue is being worked on at the moment upstream: http://public.kitware.com/Bug/view.php?id=12037#c26801 ... Modestas Vainius wrote: 2) Will those patches be part of 2.8.5? I want to emphasize that released Ubuntu 11.04 (natty) already has this multiarch enabled so upstream cmake up to and including 2.8.4 is basically unusable on those systems. That's because libc6 package is multiarch enabled and e.g. vanilla cmake 2.8.4 is not even able to set CMAKE_DL_LIBS properly. ... IMHO cmake (current git master) does not handle this new libc6 layout for multiarch support 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' 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. It rather seems that certain library packages need to be adapted to the multiarch build and libc6-dev *now* works together with cmake but libxt-dev does not. 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. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: Bug#630167: Bug#629815: No rule to make target `/usr/lib/libdl.so'
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-dev5.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.
Bug#629815: No rule to make target `/usr/lib/libdl.so'
On Thu, Jun 9, 2011 at 11:27 PM, Andreas Tille andr...@an3as.eu wrote: On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote: The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in incoming. It has a different multiarch implementation. $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-4_amd64.deb) ... I: new cache content cmake_2.8.4+dfsg.1-4_amd64.deb added No change. :-(( Any further hint? I think the issue is being worked on at the moment upstream: http://public.kitware.com/Bug/view.php?id=12037#c26801 ... Modestas Vainius wrote: 2) Will those patches be part of 2.8.5? I want to emphasize that released Ubuntu 11.04 (natty) already has this multiarch enabled so upstream cmake up to and including 2.8.4 is basically unusable on those systems. That's because libc6 package is multiarch enabled and e.g. vanilla cmake 2.8.4 is not even able to set CMAKE_DL_LIBS properly. ... IMHO cmake (current git master) does not handle this new libc6 layout for multiarch support -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: No rule to make target `/usr/lib/libdl.so'
On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote: However, the problem I was facing in the not yet released package ginkocadx[1] seems to be quite common currently. It is in #629815 and some similar case happens in #618094 and thus I'm suspecting a general problem somehow. So I'm moving the discussion to debian-mentors and hope for some clever advise what to do now. The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: No rule to make target `/usr/lib/libdl.so'
On 2011-06-09 11:19 +0200, Andreas Tille wrote: On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote: The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in incoming. It has a different multiarch implementation. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: Multiarch with cmake seems to cause FTBFS (Was: Bug#629815: No rule to make target `/usr/lib/libdl.so')
Hi, in case people might wonder about strange FTBFS like #629815 (which does not seem to be the only bug of this type): There is a fair chance that this will solve with some (future?) cmake package version. Just to let you know before everybody needs to do the same investigation ... On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote: On 2011-06-09 11:19 +0200, Andreas Tille wrote: On Thu, Jun 09, 2011 at 10:00:40AM +0200, Sven Joachim wrote: The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in incoming. It has a different multiarch implementation. I'll try, thanks for the tip Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629815: No rule to make target `/usr/lib/libdl.so'
On Thu, Jun 09, 2011 at 01:02:56PM +0200, Sven Joachim wrote: The problem is that libdl.so has been moved to the multiarch paths in libc6-dev 2.13-5. You must upgrade cmake to 2.8.4+dfsg.1-3, have you done that already? I'm building an unstable pbuilder chroot. It is using the cmake version you are mentioning: $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-3_amd64.deb) ... Might be worth retrying with cmake 2.8.4+dfsg.1-4, currently in incoming. It has a different multiarch implementation. $ grep cmake.2\.8 ginkgocadx_2.4.1.1-1_amd64.build Unpacking cmake (from .../cmake_2.8.4+dfsg.1-4_amd64.deb) ... I: new cache content cmake_2.8.4+dfsg.1-4_amd64.deb added No change. :-(( Any further hint? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
