Re: Workaround for the *LibraryDepends.cmake issue
Anyone ? I cannot do a NMU, as I am DM, but I can confirm this is a
good fix. I did use something very close in the past to remove
explicit dep to libssl from my gdcm generated cmake files.
This would be great if this issue would be fixed.
thanks
On Tue, Aug 16, 2011 at 9:19 PM, Michael Schutte <michi@debian.org> wrote:
> tags 506992 + patch
> tags 635300 + pending
> thanks
>
> Hi everyone,
>
> Yesterday I found some time to dive into the problem with full .so paths
> in VTK and ITK, which currently cause frequent FTBFSes because of more
> and more libraries moving down the directory hierarchy for multiarch. I
> suggest this workaround for the issue: In debian/rules, run
>
> sed -i -e "s#/usr/lib/\(`dpkg-architecture -qDEB_HOST_MULTIARCH`/\)\?lib\([^;]*\)\.so#\2#g" \
> $(path_to_library_depends)
>
> after building. While I haven’t found a way to avoid getting the
> absolute paths in the first place, CMake does manage to find libraries
> in default locations. This isn’t pretty, but we can remove it again
> after all required libraries are “multiarched” – particularly when VTK
> and ITK undergo that transition themselves ;-)
>
> The other fixes I tried, namely removing *LibraryDepends.cmake
> altogether, and converting to another way to use CMake, sadly don’t work
> satisfactorily. The former breaks some builds, the latter is a lot of
> work and doesn’t fix the problem completely.
>
> This one should be a low-maintenance solution, and AFAICT it works out
> fine. I locally test-built ants, elastix, gdcm, ginkgocadx, gofigure2
> and ifrit, all of which depend on libinsighttoolkit3-dev, libvtk5-dev or
> both (there are more, but my machine is slow). The fix for ITK is
> committed and ready to upload. For VTK, please try the attached patch.
>
> Cheers,
> --
> Michael Schutte | michi@{uiae.at,debian.org}
> Innsbruck, Austria | happily accepting encrypted mail
> OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
>
--
Mathieu
Reply to: