|
Notes |
|
|
(0035908)
|
|
Nico Schlömer
|
|
2016-04-20 17:12
|
|
|
I dug a little further and found that the version restriction on GL2PS is probably too loose. VTK, it seems, required GL2PS 1.3.9. |
|
|
|
(0035955)
|
|
Peter Mattern
|
|
2016-05-14 19:49
|
|
This problem is not related to the GL2PS version as it can be seen exactly as depicted above compiling recent VTK master against GL2PS 1.3.9 or 1.3.8 on Arch Linux or Debian testing.
Rather, it's a regression introduced in commit ea116f0 on 2016-01-25. The problem can not be seen compiling its predecessor commit 7c5d91d. Again the findings are the same compiling these commits against GL2PS 1.3.9 or 1.3.8 on Debian testing. (They cannot be compiled on Arch Linux easily any longer as the distribution is using GCC 6 by now and compatibility with this version was added to VTK in March 2016 only).
IMO it would be good to change the Type to "incorrect functionality" and increasing the severity to "major" would eventually be justifiable as well.
Of course the latter only makes sense if compatibility with system libraries in the *ix ecosystem is somehow a priority. New to VTK and looking at bugs http://www.vtk.org/Bug/view.php?id=15549 [^] (NetCDF) and in particular http://www.vtk.org/Bug/view.php?id=14126 [^] (PROJ.4, patch pending for nearly 3 years) I'm not sure whether this applies to this otherwise pretty active project, though.
Note on Debian:
Debian and hence derivatives like *buntu as well are currently shipping GL2PS shared libraries with a wrong soname, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824357. [^] While I could not see any manifest failure due to this it may eventually be better to use GL2PS compiled from the sources to trace the problem we're discussing here. As for 1.3.8 a patch is needed to compile on recent distributions like Arch Linux, Debian testing, Fedora 23 or openSUSE Leap 42.1. It can e. g. be extracted from the openSUSE source files provided at http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/suse/src/gl2ps-1.3.8-9.1.src.rpm.mirrorlist [^] ("no-copy-dt-needed-entries.patch"). |
|
|
|
(0036290)
|
|
Dan Lipsa
|
|
2016-07-06 16:48
|
|
|
Note that VTK includes its only version of GL2PS (with mangled symbols) exactly to get around problems with using various versions of GL2PS. Dave do you have more insights on why this linking fails? |
|
|
|
(0036325)
|
|
David C. Lonie
|
|
2016-07-07 09:02
|
|
What's happened here is that GL2PS is no longer compatible with modern OpenGL, as it heavily depends on features that have been deprecated. These features are no longer available in VTK's new OpenGL2 backend.
To get things working in the new backend, I patched GL2PS to work around some of the incompatibilities. These changes are included in the version of GL2PS bundled with VTK's source code. They've also been accepted upstream, but have not made it into a release yet.
So there are three short-term solutions you can take for packaging:
1) Use the older, slower OpenGL backend. This should build fine against an older GL2PS, but will not take advantage of the newer rendering engine. In CMake, this is VTK_RENDERING_BACKEND=OpenGL.
2) Use the version of GL2PS bundled with VTK. We mangle symbol names in our internal libraries so you shouldn't have to worry about linker conflicts if there's another GL2PS installed. This is CMake option VTK_USE_SYSTEM_GL2PS=OFF.
3) Build against the SVN version of GL2PS available here: http://www.geuz.org/gl2ps/ [^]
I'd go with 2.
BTW, where did you see VTK's minimum version of GL2PS listed as 1.3.8? I'll update that to reflect these changes. |
|