| Summary: | sci-visualization/paraview-3.2.1 fails to save png/jpeg snapshots | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matthias Langer <m.langer798> |
| Component: | Current packages | Assignee: | Markus Dittrich (RETIRED) <markusle> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | oli.borm, sci, tfroebel |
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
CMakeCache.txt
CMakeCache.txt used by the ebuild (fails) CMakeCache.txt generated manually by ccmake (works) |
||
|
Description
Matthias Langer
2008-05-05 22:05:51 UTC
Hi Matthias, Thanks much for the note. How did you compile the cvs snapshot: Did you use system jpeg/png/tiff libraries (like the ebuild does) or the ones supplied by paraview? Thanks, Markus Created attachment 152173 [details] CMakeCache.txt > How did you compile the cvs snapshot: > Did you use system jpeg/png/tiff libraries (like the ebuild > does) or the ones supplied by paraview? Actually I used system libraries wherever possible; this includes jpeg/png/tiff like the ebuild does, but also boost and ffmpeg (seems to work with current cvs versions). For details please refer to CMakeCache.txt which is attached. Thanks, Matthias Thanks, Matthias. This implies that the issue is actually within paraview since the cvs version seems to work for you. I'll see if I can figure out what the issue could be. Best, Markus (In reply to comment #3) > Thanks, Matthias. This implies that the issue > is actually within paraview since the cvs version > seems to work for you. I'll see if I can figure out > what the issue could be. > Hmm, maybe we should better just bump paraview-3.3.0_pre20080505 or something like that, as if the bug is actually in paraview, this seems to be the most natural (and least painful) approach. If you want, I can attach an appropriate ebuild in the next few days... Yeah, we'll have to see. It depends a lot on how stable their current cvs version is overall. I don't use paraview very much in my daily work so it is hard for me to tell. Maybe scanning the mailing lists/cvs commits will help digging up a patch for this specific problem. Best, Markus well, to be honest i don't use paraview very much myself; however, the head of our research group does, and he told me, that the version i've compiled from cvs works considerably better than paraview-3.2.1; he did not mention any regressions. so i think, that hacking together a patch, that may introduce it's own issues, is not worth the effort; of course, what i'm talking about is the version i checked out about three days ago. it is therefore possible, that in the meantime, some regressions have been introduced... According to the newsgroups the screenshot facility seems pretty broken in the latest stable release and compiling cvs HEAD looks like the only good alternative short of digging up the offending pieces of code and rolling a separate patch. I'll probably pull a snapshot but will have to test it a bit before bumping the ebuild. Thanks, Markus thank you very much! if you want me to help with testing, just point me to the ebuild & the snapshot, so that i can take a look. btw. i've been trying to assemble an ebuild for the snapshot i'm using... unfortunately, cmake seems to behave a bit differently when called by portage, and i got compile-time failures. as my time is rather limited atm i did not yet do any further investigations. i'm sorry... just one minor side-note: when building paraview directly, cmake suggests compiling with "-DNDEBUG". maybe the ebuild should append this flag... thanks again, matthias I can also confirm this bug on amd64 and x86 machines with paraview-3.2.1 from portage and the proprietary nvidia drivers. If you switch to the xorg-x11 opengl drivers with eselect, then the screenshots are not black anymore. If I use debian on the same machine with the proprietary nvidia drivers and the debian paraview-3.2.1 package, then the pictures are also not black. I've just committed paraview-3.3_pre20080514 to portage. It is currently hard masked for a bit more testing. So far, everything seems to work fine for me. Please give it a spin and let me know of any problems. Best, Markus on amd64: sci-visualization/paraview-3.3_pre20080514 USE="mpi qt4 threads -doc -examples -hdf5 -python" seems to work very well for me; especially, saving jpeg/png snapshots works. btw: is there a reason you are using "emake -j1"? i've just removed "-j1" and was able to build paraview with "-j3" on a dual-core machine ($box2 from comment 0)... tomorrow i'll try the same on $box1 from comment 0 (8 cores, -j9) just to be sure. I am glad to hear it works for you. I'll give it a few more days of testing and will then unmask it. Regarding the "-j1": It consistently fails on my opteron with -j5. If it works for you feel free to remove it ;) cheers, Markus hmm, for some reason sci-visualization/paraview-3.3_pre20080514 USE="doc examples python qt4 threads -hdf5 -mpi" fails with " [ 22%] Building CXX object VTK/Rendering/Testing/Cxx/CMakeFiles/TestFBOImplementation.dir/TestFBOImplementation.o /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx: In function 'const char* TextureCompressionFormat(GLint)': /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx:376: error: 'COMPRESSED_SRGB_S3TC_DXT1_EXT' is not a member of 'vtkgl' /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx:379: error: 'COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT' is not a member of 'vtkgl' /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx:382: error: 'COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT' is not a member of 'vtkgl' /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx:385: error: 'COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT' is not a member of 'vtkgl' /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx: In function 'const char* InternalTextureFormatToString(int)': /var/tmp/portage/sci-visualization/paraview-3.3_pre20080514/work/ParaView3/VTK/Rendering/Testing/Cxx/TestFBOImplementation.cxx:571: error: 'SRGB8' is not a member of 'vtkgl' [...] * * ERROR: sci-visualization/paraview-3.3_pre20080514 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3145: Called die * The specific snippet of code: * emake -j1 || die "emake failed" " on $box1 from comment 0 while sci-visualization/paraview-3.3_pre20080514 USE="mpi python qt4 threads -doc -examples -hdf5" works on $box2 from comment 0. The only difference in USE is mpi; both boxes use cmake-2.4.6-r1. I'm going to to look into this further... What OpenGl implementation is used on both machines? emerge sci-visualization/paraview-3.3_pre20080514 USE="doc examples hdf5 python qt4 threads -mpi" with nvidia-drivers: x11-drivers/nvidia-drivers-169.09-r1 USE="acpi -custom-cflags -gtk (-multilib)" seems to solve the problem. I'm able to make some png screenshots without switching opengl to xorg. Tobias (In reply to comment #14) > What OpenGl implementation is used on both machines? well, that might make the difference; both use nvidia, but (pasting from comment 0) $box1: 02:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GT (rev a2) nvidia-drivers-169.12 USE="acpi gtk -custom-cflags (-multilib)" $box2: VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1) nvidia-drivers-169.09-r1 USE="acpi gtk -custom-cflags (-multilib)" the problem is, that i can't downgrade on $box1, because the older drivers just don't work there at all. btw.: that i'm getting errors (see comment 13) in /ParaView3/VTK/Rendering/Testing/Cxx/ seems a bit odd to me, because i did not activate FEATURES="test". maybe the build gets there anyway - but maybe it should not. thus, i'm going to upgrade cmake on $box1 (although i use the same version of cmake on $box2) to see if that helps. if that fails too, i'll try to compile the snapshot manually. (In reply to comment #16) > (In reply to comment #14) > > What OpenGl implementation is used on both machines? > > well, that might make the difference; both use nvidia, but (pasting from > comment 0) > > $box1: > 02:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GT (rev a2) > nvidia-drivers-169.12 USE="acpi gtk -custom-cflags (-multilib)" > > $box2: > VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1) > nvidia-drivers-169.09-r1 USE="acpi gtk -custom-cflags (-multilib)" > > the problem is, that i can't downgrade on $box1, because the older drivers just > don't work there at all. > I have 169.12 and can compile it just fine, so that's probably not it then. Did you make sure that nvidia's gl libs are selected via eselect when you compiled it? Thanks, Markus > Did you make sure that nvidia's gl libs are selected via
> eselect when you compiled it?
i'm sure that i didn't change anything opengl-related since the last month, and:
"
# eselect opengl show
nvidia
"
let's see if it works with another version of cmake...
well, it fails exactly the same way with dev-util/cmake-2.4.8 USE="vim-syntax -emacs" but i can compile it manually without any problems (and -j9). Created attachment 154073 [details]
CMakeCache.txt used by the ebuild (fails)
Created attachment 154075 [details]
CMakeCache.txt generated manually by ccmake (works)
The diffs between the two cmake cache files are unfortunately too large for me to track down what the issue may be. If any of these boxes has vtk installed as well could you remove it temporarily and see if that helps. There have been weird library clashes in the past. Otherwise, the only reliable way to track down the offending piece is to remove all cmake options one at a time until it compiles (since the vanilla compile seems to work for some reason). Best, Markus (g)vimdiff is your friend ;-). actually i get (compare with the error in comment 13) " [ 16%] Building CXX object VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkOpenGLRenderWindow.o /home/mlangc/playground/Paraview-markusle/ParaView3/VTK/Rendering/vtkOpenGLRenderWindow.cxx: In member function 'int vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow(int, int)': /home/mlangc/playground/Paraview-markusle/ParaView3/VTK/Rendering/vtkOpenGLRenderWindow.cxx:1640: error: 'DEPTH_STENCIL_EXT' is not a member of 'vtkgl' make[2]: *** [VTK/Rendering/CMakeFiles/vtkRendering.dir/vtkOpenGLRenderWindow.o] Error 1 make[1]: *** [VTK/Rendering/CMakeFiles/vtkRendering.dir/all] Error 2 make: *** [all] Error 2 " when manually compiling paraview, after applying only this "patch": " $ diff -u CMakeCache.txt.box1.manual CMakeCache.txt.box1.portage | grep \ '\<glext.h$' -VTK_GLEXT_FILE:FILEPATH=/home/mlangc/playground/Paraview-markusle/ParaView3/VTK/Utilities/ParseOGLExt/headers/glext.h +VTK_GLEXT_FILE:FILEPATH=/usr/include/GL/glext.h " thanks for your patience, matthias Ahh, thanks for tracking this down. Could you please check if your installed /usr/include/GL/glext.h is in good shape? It belongs to eselect-opengl so you may just want to re-emerge it. My system glext.h is version 39 and VTK's is slightly newer (version 40) but both files are virtually identical apart from so comments. Best, Markus now everything becomes clear:
on $box2 i'm using eselect-opengl-1.0.6-r1 and paraview works. on $box1 however, which is a production machine and doesn't get updated that often, i was still using eselect-opengl-1.0.5, and:
"
$ cat /usr/lib64/opengl/global/include/glext.h | grep GL_GLEXT_VERSION
#define GL_GLEXT_VERSION 29
"
after upgrading eselect-opengl, i was finally able to emerge paraview-3.3_pre20080514 on $box1
"
[...]
>>> sci-visualization/paraview-3.3_pre20080514 merged.
"
(with -j9, maybe your parallel build failures are tied to a specific version of cmake?)
so, i guess adding ">=app-admin/eselect-opengl-1.0.6-r1" (i don't know if it works with 1.0.6) to DEPEND should finally fix this problem.
thanks,
matthias
Great! I'll add eselect-opengl-1.0.6-r1 as a dependency. I think the parallel make issues only happen with gcc-4.3.0 probably since the compile timings are different (faster/slower, not quite sure which one). I still wanted to look into getting the new ebuild compile against qt-4.4 which currently seems to break things. Thanks again for your help in debugging this. Best, Markus just a note: sci-visualization/paraview-3.3_pre20080514 USE="examples hdf5 python qt4 threads -doc -mpi" also seems to work fine here: Portage 2.1.4.4 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.7-r2, 2.6.24-gentoo-r7 i686) ================================================================= System uname: 2.6.24-gentoo-r7 i686 Intel(R) Pentium(R) 4 CPU 3.40GHz Timestamp of tree: Tue, 27 May 2008 02:45:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.3.5-r3, 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=prescott -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub" LC_ALL="en_US.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acpi aiglx alsa berkdb browserplugin bzip2 cairo caps cli cracklib crypt cups dbus dlloader dri dvd dvi emboss encode fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg ldap mad midi mikmod mmx mp3 mpeg mudflap nautilus ncurses nls nptl nptlonly nsplugin nvidia ogg opengl openmp pam pcre perl png ppds pppd python quicktime readline reflection ruby sdl session spell spl sse sse2 ssl svg tcpd threads tiff truetype unicode usb vim-syntax vorbis win32codecs x86 xinerama xml xorg xprint xv zlib" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Thanks much for the note and I've just unmasked paraview. Qt-4.4 should now also work properly as far as I can tell. Thanks again for all the help! Best, Markus |
