Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

ebuild attached below.

Created an attachment (id=80015) [details]
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) [details]
ebuild with Qt support

(From update of attachment 80421 [details])
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) [details]
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) [details]
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) [details]
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) [details]
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) [details]
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 [details])
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) [details]
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