The comment in the ebuild states that ecj is used as javac runs out of memory (not that surprising as the java default heap size is only 64MB). The correct solution to this problem is to increase the amount of memory available to javac, not force the use of a specific alternative compiler. Do something like "javac -J-Xmx256m". sci-libs/vtk and dev-util/weka both hardcode this in the ebuild, obviously it would be nice if this were done in a more generic way only when javac is used as the system compiler.
This was done previously, only for amd64 where the problem arised first (see bug 119400), then there was somebody who couldn't compile it even with 2048m limit (bug 141528). And on bug 144760 you can see it's hitting amd64 as well. So trying to fix javac is not easy, if not impossible for all cases. We even consider making ecj default compiler.
(In reply to comment #1) > limit (bug 141528). And on bug 144760 you can see it's hitting amd64 as well. s/amd64/x86/
The bug reports only say that increasing the amount of heap memory on amd64 makes no difference. I don't know why - I have no access to amd64 hardware to test. If it is the case that the jdk is broken on amd64, then there should be an open bug for this, and a bug should be filed upstream. The reported case of x86 failing is because the java runtime really is running out of heapspace - your initial ebuild doesn't alter the maximum heap space. The azureus-2.5.0.0 ebuild will compile fine on x86,sun-jdk-1.5.0.08, with ANT_OPTS="-Xmx128m".
Even if increasing the maximum stack does address the problem, I do believe it is better to use ecj, as it seems to build fine every time and every arch. Plus, it ends up using less memory while doing so. Sounds like win-win to me. Is there some particular reason that using ecj is not appropriate to you?
I just don't think forcing the compiler is the right answer. If a package fails to build with gcc, but works with icc, it would be considered unusual to workaround the problem by forcing the compiler to icc rather than fixing the gcc compile flags or tracking down the gcc bug and reporting it upstream. The same goes for compiling java. The other argument is that it is inconsistent to use ecj for just one package. If it is preferred over Sun's compiler, then it should be used to build all packages, not just azureus.
(In reply to comment #5) > I just don't think forcing the compiler is the right answer. If a package fails > to build with gcc, but works with icc, it would be considered unusual to > workaround the problem by forcing the compiler to icc rather than fixing the > gcc compile flags or tracking down the gcc bug and reporting it upstream. The > same goes for compiling java. The other argument is that it is inconsistent to > use ecj for just one package. If it is preferred over Sun's compiler, then it > should be used to build all packages, not just azureus. > ecj will indeed be our default in the future. Just don't want to do too many changes in one go as we have the gen 2 stuff to get stabilized.
I've revisited the related bugs and ebuild in sources.gentoo.org and I think all the tests with ANT_OPTS didn't export it, thus had no effect.
(In reply to comment #7) > I've revisited the related bugs and ebuild in sources.gentoo.org and I think > all the tests with ANT_OPTS didn't export it, thus had no effect. > 01:55 <@Caster> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/azureus/azureus-2.4.0.2.ebuild?hideattic=0&rev=1.2&view=markup 01:56 <@Caster> and that's when the tests happened 01:57 <@Betelgeuse> Caster: well it works if ANT_OPTS is exported at that point http://viewcvs.gentoo.org/viewcvs.py/gentoo-x86/net-p2p/azureus/azureus-2.3.0.6-r1.ebuild?hideattic=0&rev=1.2&view=markup
Stupid paste. Here is the missing part: 01:58 <@Caster> so once it's exported by a env.d file, any non-exporting change in ebuild environment affects that too? 01:58 <@Betelgeuse> yes But ant doesn't install this env.d file any more.
OK, 2.4.0.1-r1 (unstable) removes ecj dep/force and goes back to using 256m limit for amd64 and 128m for x86, which now should work because ANT_OPTS is exported.
