GL2PS library detected in /usr/lib only
pmattern opened this issue · 2 comments
The shared library of GL2PS doesn't get detected in /usr/lib/x86_64-linux-gnu/ where it's located on Debian but apparently in /usr/lib/ only. This is in contrast to all other shared libraries which get very well detected at the former location and causes FTBFS
[100%] Building CXX object ginkgocadx/CMakeFiles/ginkgocadx.dir/main.cpp.o
make[2]: *** No rule to make target '/usr/lib/libgl2ps.so', needed by 'ginkgocadx/ginkgocadx'. Stop.
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:174: recipe for target 'ginkgocadx/CMakeFiles/ginkgocadx.dir/all' failed
make[1]: *** [ginkgocadx/CMakeFiles/ginkgocadx.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
Compiling terminates successfully after creating a symbolic link /usr/lib/libgl2ps.so pointing to /usr/lib/x86_64-linux-gnu/libgl2ps.so.
Seen compiling a8819b7 on Debian testing.
Please check "/usr/lib/cmake/vtk-6.?/Modules/vtkgl2ps.cmake", because this is where the library gets pulled in. Normally, ginkgocadx wouldn't need to link against this library, but the vtk-generated module pulls it in. If it points to /usr/lib/libgl2ps.so then you are using an old version of VTK that was compiled against a version of gl2ps that is not multilib. Recompiling vtk or upgrading to the latest version in unstable should fix this.
For reference see also this bug that describes a similar case.
As a side note: If you want to test compile on Debian testing you might want to check out the Debian PTS for Ginkgo first, because it will tell you whether there are known problems. In this case it indicated that the package in int current state will be removed from testing because of the bug I indicated above (A binNMU will fix this soon though).