| Summary: | sci-libs/vtk-5.0.3 ebuild fails on amd64 with java.lang.OutOfMemoryError | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rolf S. Arvidson <rsa4046> |
| Component: | New packages | Assignee: | Markus Dittrich (RETIRED) <markusle> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Rolf S. Arvidson
2007-05-07 14:59:57 UTC
Hi Rolf, Thanks for pointing this out and for testing. I'll merge this fix back into vtk-5.0.3. then. Best, Markus (In reply to comment #0) > > + # fix java.lang.OutOfMemoryError on amd64 (see bug #123178) > + if use java && [ "${ARCH}" == "amd64" ]; then > + sed -e "s/javac/javac -J-Xmx256m/" \ > + -i "${S}"/Wrapping/Java/CMakeFiles/VTKBuildAll.dir/build.make \ > + || die "Failed to patch javac" > + fi > + > emake -j1 || die "emake failed" > } > A better solution would be to make the build system respect JAVACFLAGS and submit that patch upstream. Currently the ebuild seems to restrict to =virtual/jdk-1.5*, but it's quite likely that it works just fine with 1.6 too if the build uses JAVACFLAGS properly. JAVACFLAGS is defined in java eclasses so you should append to it. Please use attachments for patches in the future instead of inlining them. Does it really require javac etc at runtime? Most like you should have just >=virtual/jre-1.5 in RDEPEND. Hi Petteri, Thanks much for your comments. > A better solution would be to make the build system respect JAVACFLAGS and > submit that patch upstream. Upstream is aware of it but has not merged it into their current release branch and I am not sure if they will. > Currently the ebuild seems to restrict to > =virtual/jdk-1.5*, but it's quite likely that it works just fine with 1.6 too > if the build uses JAVACFLAGS properly. JAVACFLAGS is defined in java eclasses > so you should append to it. jdk-1.6 likely works but I haven't tested it (yet). VTK uses cmake and as far as I know cmake does not know about JAVACFLAGS hence appending to it won't work. Please correct me if I am wrong. > Does it really require javac etc at runtime? Most > like you should have just >=virtual/jre-1.5 in RDEPEND. I assume you meant DEPEND here? You bring up a very good point here, thanks. Since vtk is a library, in principle all of RDEPEND could go to DEPEND. What would you suggest? Thanks, Markus (In reply to comment #3) > I assume you meant DEPEND here? You bring up a very good point > here, thanks. Since vtk is a library, in principle all of RDEPEND could > go to DEPEND. What would you suggest? > Ok, I was clearly too fast here; in addition to its libs vtk also provides a bunch of wrappers that need most of the stuff in RDEPEND. However, >=virtual/jre-1.5 can go ito DEPEND. I'll fix this tomorrow and will also give jre-1.6 a spin. Thanks, Markus (In reply to comment #4) > > Ok, I was clearly too fast here; in addition to its libs vtk also provides > a bunch of wrappers that need most of the stuff in RDEPEND. However, > >=virtual/jre-1.5 can go ito DEPEND. I'll fix this tomorrow and will also > give jre-1.6 a spin. > > Thanks, > Markus > virtual/jdk provides a virtual/jre > > jdk-1.6 likely works but I haven't tested it (yet). VTK uses cmake and as far > as > I know cmake does not know about JAVACFLAGS hence appending to it won't work. > Please correct me if I am wrong. > Yes the build tool needs to know about it the same way as Makefiles know how to use CFLAGS. gcc doesn't use CFLAGS and neither does javac use JAVACFLAGS. I've just committed the patched ebuild to cvs and also changed the dependency to >=virtual/jdk-1.5. Please ping me if you find any other issues with the java stuff currently implemented in the ebuild. I'll see if I can contact the vtk folks about fixing this in their next release. Thanks, Markus |
