Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
ebuild attached below.
Created an attachment (id=80015) [edit] vtk-5.0.0.ebuild The ebuild is based on vtk-4.2.6.ebuild. Some minor problems had to be fixed. The ebuild works fine on my laptop (dell lattitude D800), with all options, except MPI, enabled.
Created an attachment (id=80421) [edit] ebuild with Qt support
(From update of attachment 80421 [edit]) This ebuild still tries to patch some files, but the patch was not submitted and the 4.2.6 patch does not apply, so it is removed from the ebuild. Also added Qt support if requested by USE: VTK_USE_GUISUPPORT VTK_USE_QVTK QT_WRAP_CPP QT_WRAP_UI Not sure if this is related to <a href="http://bugs.gentoo.org/show_bug.cgi?id=51197">bug #51197</a>. By adding QT I get some sandbox violations, but I have no idea on how to correct it (disabling VTK_USE_QVTK and VTK_USE_GUISUPPORT works): --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-sci-libs_-_vtk-5.0.0-27476.log" open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock -------------------------------------------------------------------------------- Other warnings I receive (also with the original ebuild): It is impossible to order the linker search path in such a way that libraries specified as full paths will be picked by the linker. Directories and libraries involved are: Directory: /usr/X11R6/lib contains: Library: /usr/lib/libGL.so Library: /usr/lib/libexpat.so Library: /usr/lib/libjpeg.so Library: /usr/lib/libpng.so Library: /usr/lib/libtiff.so Library: /usr/lib/libz.so Directory: /usr/lib contains: Library: /usr/X11R6/lib/libX11.so Library: /usr/X11R6/lib/libXext.so emerge info: Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.14-gentoo-r5 i686) ================================================================= System uname: 2.6.14-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O9 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O9 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://mirror.nutsmaas.nl/gentoo/" LINGUAS="en_GB nl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="x86 X aac aalib acpi alsa apm arts audiofile avi bash-completion bcmath berkdb bitmap-fonts blas bzip2 cdparanoia crypt cups curl dga eds emboss encode examples exif expat fam ffmpeg fftw foomaticdb fortran ftp gd gdbm gif glut gphoto2 gpm gstreamer gtk2 hal idn imagemagick imap imlib ipv6 java jikes jpeg jpeg2k kde lapack lcms libg++ libwww mad matroska mhash mikmod mng motif mozilla mp3 mpeg ncurses nls ogg oggvorbis openal opengl opgengl oss pam pcre pdflib perl php png python qt quicktime readline samba sdl spell sse ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts udev usb vorbis win32codecs wmf xine xml2 xmms xv xvid zlib video_cards_i830 linguas_en_GB linguas_nl userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Created an attachment (id=80425) [edit] vtk-5.0.0-gcc34.patch Sorry, I forgot to attatch the patch file. I'm not sure what problem it fixes.
Hi, Thanks for the ebuilds and patches. I'll have a look at it over the weekend. Thanks, Markus
Created an attachment (id=80930) [edit] Working ebuild.
This ebuild works. Several bugs are solved. The previously reported problem seemed to be related to a qtrc bug, which could be solved by adding: addwrite "${QTDIR}/etc/settings" when using QT. Another bug solved is that VTK does not compile when MAKEOPTS='-j3' or higher. For safety the build defaults to emake -j1. I also added the VTK_DIR=/usr/lib/vtk-5.0 to /etc/env.d/40vtk to make 'cmake' work properly. Only one error I cannot solve, but it isn't a fatal one: # fix config file sed -i -e "s:${D}:/:g" ${D}/usr/$(get_libdir)/${PN}/VTKConfig.cmake gives an error. Now going to try with qt4 :)
Created an attachment (id=80983) [edit] vtk ebuild Hi Sebastiaan, Thank you very much for all the work. I attached an ebuild that seems to work fine for me. Unfortunately, I haven't been able to generate the html docs yet. It currently only works with QT3 and I'd suggest to keep it that way for now until any remaining issues are ironed out. Please give it a shot and report back. Thanks in advance, Markus
Created an attachment (id=81044) [edit] vtk-5.0.0-r4.ebuild I saw you did some cleaning in the original ebuild, so I started on from this one. It did not really emerge cleanly, due to several reasons, of which most are fixed: 1. still need cmake -j1, otherwise the compilation is aborted (dependencies in the compilation process) 2. examples were not built anymore -> added missing ${S} to the pathname 3. VTK_DIR needs to be set in /etc/env.d/40vtk Then some quirks from my situation :) 1. I had to use an amd64 today, and the compilation broke on the blackdown-jre path -> replaced i386 by ${ARCH}, with an exception for x86 (blackdown uses i386 as directory then). 2. When QT3 and QT4 are both installed, VTK does not know which version to choose. When QT4 is available, it defaults to QT4. However, if you want QT3 support, some additional paths have to be set (e.g. use /usr/qt/3/bin/moc in stead of /usr/bin/moc for QT4). If you want to use QT3 when QT4 is installed, you have to comment out the QT4 stuff, but there must be a nicer way to do this. Problems still to solve: 1. unsuccesfull build on my amd64: Java complains about 'Out of Memory' (FYI: 1GB is installed, and I have been able to build VTK with 512MB on another machine) 2. not sure if we need to inherit qt4 at the beginning of the ebuild 3. (old) generate HTML docs
I have done some additional research on the java error. This is where the build ends: (...) Listing /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Python/vtk/wx ... Compiling /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Python/vtk/wx/__init__.py ... Compiling /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Python/vtk/wx/wxVTKRenderWindow.py ... Compiling /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Python/vtk/wx/wxVTKRenderWindowInteractor.py ... ... Generating ../../java/vtk/vtkBuildAllDriver.class The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError make[2]: *** [java/vtk/vtkBuildAllDriver.class] Error 3 make[1]: *** [Wrapping/Java/CMakeFiles/VTKBuildAll.dir/all] Error 2 make: *** [all] Error 2 !!! ERROR: sci-libs/vtk-5.0.0-r4 failed. !!! Function src_compile, Line 123, Exitcode 2 !!! emake failed !!! If you need support, post the topmost build error, NOT this status message. So, looking at /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Java/CMakeFiles/VTKBuildAll.dir/build.make and picking out the line where the error originates: <snip> java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaCommonDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaFilteringDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaGraphicsDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaIODriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaImagingDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaWidgetsDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaHybridDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaVolumeRenderingDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkVTKJavaRenderingDriver.java java/vtk/vtkBuildAllDriver.class: java/vtk/vtkBuildAllDriver.java @echo "Generating ../../java/vtk/vtkBuildAllDriver.class" cd /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Java && /opt/blackdown-jdk-1.4.2.03/bin/javac -classpath /var/tmp/portage/vtk-5.0.0-r4/work/VTK/ java/vtk/.. -d /var/tmp/portage/vtk-5.0.0-r4/work/VTK/java/vtk/.. /var/tmp/portage/vtk-5.0.0-r4/work/VTK/java/vtk/vtkBuildAllDriver.java </snip> However, running the command by hand (in a sandboxshell environment), the source is compiled without errors. I think this is a bug from blackdown-jre on amd64 platform since it compiles without problems on x86. Nevertheless, it would be nice if VTK compiles on amd64 as well. Any ideas?
Created an attachment (id=81388) [edit] vtk-5.0.0-r5.ebuild New ebuild which solves various problems (again): 1. Because of an error in /usr/share/cmake/Modules/FindQt4.cmake with cmake-2.2.1, >=cmake-2.2.3 is required to build VTK with QT4. 2. I have not been able to analyze the java error mentioned before. It still exists in the current CVS version as well. Simply running 'emake' twice works. 3. This also gave me an idea about the required -j1 option to succesfull build VTK. Running emake with standards MAKEOPTS several times will make use of SMP systems (-j5 for example, if available of course), and when the build breaks due to dependencies, emake is run again (the dependencies are satisfied in the second and third runs). 2. and 3. result in an ugly, but safe way (e.g. it will not break anything) to build VTK: if [ "${ARCH}" == "amd64" ]; then emake || emake || emake || emake || die "emake failed" else emake || emake || emake || die "emake failed" fi It might lead to some confusing output when a serious make problem occurs (it will be printed three or four times), but this is the easiest way to make things work without breakting anything. I am interested if this ebuild works for everybody now.
(From update of attachment 81388 [edit]) New ebuild which solves various problems (again): 1. Because of an error in /usr/share/cmake/Modules/FindQt4.cmake with cmake-2.2.1, >=cmake-2.2.3 is required to build VTK with QT4. 2. I have not been able to analyze the java error mentioned before. It still exists in the current CVS version as well. Simply running 'emake' twice works. 3. This also gave me an idea about the required -j1 option to succesfull build VTK. Running emake with standards MAKEOPTS several times will make use of SMP systems (-j5 for example, if available of course), and when the build breaks due to dependencies, emake is run again (the dependencies are satisfied in the second and third runs). 2. and 3. result in an ugly, but safe way (i.e. it will not break anything) to build VTK: if [ "${ARCH}" == "amd64" ]; then emake || emake || emake || emake || die "emake failed" else emake || emake || emake || die "emake failed" fi It might lead to some confusing output when a serious make problem occurs (it will be printed three or four times), but this is the easiest way to make things work without breakting anything. I am interested if this ebuild works for everybody now.
Re: comment 12, if someone has a cluster and uses distcc then they might use -j32 or something like that. You cannot assume the X in -jX is bounded by the number of cores directly connected to the motherboard. As I see it, there are only two possibilities: either the upstream build system is setup to build correctly with -j2 or higher or it isn't. If it is not then no amount of "emake || emake || etc" will every guarantee it will function correctly. Seems to me, the correct thing to do is force -j1 (which is what is done on other ebuilds with this issue) and perhaps open a bug upstream if their build system doesn't work with -j2.
Hi folks, I've just committed a vtk-5.0.0.ebuild to cvs. Currently, it is masked to allow for further testing. Please give it a spin and many thanks in advance to all of you for your efforts, they are much appreciated. Here are a few comments 1) Currently, the ebuild is ~x86 only since I do not have an amd box to test it. Once it is tested and removed from package.mask we can file a bug with gentoo's amd64 team to move it into ~amd64 once all the issues on this arch are ironed out. 2) I still need to work on the QT4 stuff; currently only QT3 is enabled. The ebuild should probably have a qt3/4 use flag; simply forcing qt4 if present on the user's system might not be the proper solution. 3) Java works fine here and unfortunately I can't comment on the problems on amd64. 4) Regarding the distcc issue I agree with Colin that we should force j1 and contact upstream asking them to fix their build system. I'll look into that. Thanks, Markus
Hi, tried the vtk-5.0.0 from portage. There is a typo in the DESIRED_QT_VERSION: it should be -DDESIRED_QT_VERSION (forgot the first D). To prevent errors on a mixed QT system, I would also add these: QT_MOC_EXECUTABLE:FILEPATH=/usr/qt/3/bin/moc QT_UIC_EXECUTABLE:FILEPATH=/usr/qt/3/bin/uic Since the x86 box is in production now, I cannot emerge it anymore. 'ebuild vtk-5.0.0.ebuild test' builds succesfull after making the above changes (and setting emake -j1).
(In reply to comment #15) > Hi, > > tried the vtk-5.0.0 from portage. There is a typo in the DESIRED_QT_VERSION: it > should be -DDESIRED_QT_VERSION (forgot the first D). To prevent errors on a > mixed QT system, I would also add these: > QT_MOC_EXECUTABLE:FILEPATH=/usr/qt/3/bin/moc > QT_UIC_EXECUTABLE:FILEPATH=/usr/qt/3/bin/uic > Hi Sebastiaan, Thank you very much for your feedback and testing. These changes have been applied to the ebuild in cvs. Thanks, Markus
Hi all, some additional information for amd64: The java problem can be solved by adding -J-Xmx256m to the compile options (see http://news.gmane.org/gmane.linux.gentoo.java/cutoff=818 ). Add this in the vtk-5.0.0-r5.ebuild just before the emake: # Fix java.lang.OutOfMemoryError with Blackdown on amd64 if [ "${ARCH}" == "amd64" ]; then sed -e "s/javac/javac -J-Xmx256m/" \ -i ${S}/Wrapping/Java/CMakeFiles/VTKBuildAll.dir/build.make || \ die "Failed to patch Wrapping/Java/CMakeFiles/VTKBuildAll.dir/build.make." fi Being a sed-noob, I have not succeeded to patch only this line: @echo "Generating ../../java/vtk/vtkBuildAllDriver.class" cd /var/tmp/portage/vtk-5.0.0-r4/work/VTK/Wrapping/Java && /opt/blackdown-jdk-1.4.2.03/bin/javac -classpath /var/tmp/portage/vtk-5.0.0-r4/work/VTK/ java/vtk/.. -d /var/tmp/portage/vtk-5.0.0-r4/work/VTK/java/vtk/.. /var/tmp/portage/vtk-5.0.0-r4/work/VTK/java/vtk/vtkBuildAllDriver.java Anyway, I should leave something for Markus to do ;) Another issue on amd64 is when USE=mpi and mpich is requiered. mpich needs to be compiled with -fPIC, in order to link correctly with libmpich.a. I have filed a this as bug 126774 .
Additional information: the Java error on amd64 appears with either Blackdown or Sun java installed.
Created an attachment (id=82929) [edit] vtk-5.0.0-r6.ebuild Thought it would be nice to add this Java-bug patched ebuild as well. This ebuild differs from the one in portage in amd64 and QT4 (optional) support.
Success on amd64 with the vtk-5.0.0-r6.ebuild. Blackdown. Thanks. Pete [ebuild N ] sci-libs/vtk-5.0.0 -doc -examples +java -mpi -patented +python -qt +tcltk -threads 0 kB [1]
Thanks for the patches and testing. I've updated the ebuild in portage with the java fix and qt3/qt4 is now implemented as well. Please give it a spin, it works fine for me. Unless there are any major issues, I am planning to unmask it one week from today. Thanks, Markus
Hi, in the ebuild the existance of qt3 or qt4 use-flag is checked. As far as I know, qt3 or qt4 are not official use-flags at the moment. qt is. Now when qt is in the use flags, the qt3 and qt4 checks fail, so no qt support is build at all. I think it is better when no qt3 and qt4 is found, but qt is defined, to send out an error so the user has to decide to record qt3/4 in his/her use-flags. Some packages (for example wxpython) do this then the use-flags are unclear. Another thing is the amd64. The ebuild is not marked ~amd64, so that is probably why you refrain from setting JAVA_AWT_LIBRARY correctly on amd64. That's ok. But you do apply the patch for java.lang.OutOfMemoryError on amd64. So either add ~amd64 to the keywords and fix JAVA_AWT_LIBRARY or remove the OutOfMemory fix. I suggest the former :)
(In reply to comment #22) > Hi, > > in the ebuild the existance of qt3 or qt4 use-flag is checked. As far as I > know, qt3 or qt4 are not official use-flags at the moment. qt is. Now when qt Thanks for pointing this out. They are official in the sense that they are in use.local.desc. But I agree with you that there could be confusion on the side of the user due to the existence of the global qt use flag. I'll have to think about how to best handle that. > Another thing is the amd64. The ebuild is not marked ~amd64, so that is > probably why you refrain from setting JAVA_AWT_LIBRARY correctly on amd64. > That's ok. But you do apply the patch for java.lang.OutOfMemoryError on amd64. > So either add ~amd64 to the keywords and fix JAVA_AWT_LIBRARY or remove the > OutOfMemory fix. I suggest the former :) > The missing JAVA_AWT_LIBRARY was an oversight on my part and should be fixed now. Sorry about that. Gentoo policy is that developers can only mark packages ~arch on the arches they can test, hence I can only do ~x86. Once all the amd64 bugs are ironed out (for now the mpi one) I'll file a request with the amd64 herd to do the ~amd64 marking. Thanks, Markus
I've just removed vtk-5.0.0 from package.mask and will therefore close this bug. Please open a new one if there are any additional issues. Thanks again to all for the help in testing and debugging! Best, Markus
