When emerging monodevelop-0.12 (with java use flag enabled) the dependency requires ikvm-0.34.0.2. When emerging ikvm here is what finally happens: __________________________________________________ [nant] /var/tmp/portage/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build Buildfile: file:///var/tmp/portage/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build Target framework: Mono 1.0 Profile Target(s) specified: IKVM.GNU.Classpath.dll jars: classes: [exec] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space BUILD FAILED - 0 non-fatal error(s), 1 warning(s) /var/tmp/portage/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build(27,10): External Program Failed: /usr/bin/ecj-3.2 (return code was 1) Total time: 32.9 seconds. BUILD FAILED Nested build failed. Refer to build log for exact reason. Total time: 44 seconds. !!! ERROR: dev-dotnet/ikvm-0.34.0.2 failed. Call stack: ebuild.sh, line 1615: Called dyn_compile ebuild.sh, line 972: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ikvm-0.34.0.2.ebuild, line 36: Called die !!! ikvm build failed Reproducible: Always Steps to Reproduce: 1. emerge ikvm (or emerge monodevelop, with java use flag enabled) Actual Results: Check the description for a quote from the log. Expected Results: Successful build of ikvm. I think memory requirement for x64 systems is double than for x86. I want to find out how to modify the ebuild to instruct ecj to use more memory. I think this would fix the ebuild's problem.
Portage 2.1.2.7 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r3, 2.6.20-gentoo-r8_vyper_v0.1 x86_64) ================================================================= System uname: 2.6.20-gentoo-r8_vyper_v0.1 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-52 Gentoo Base System release 1.12.9 Timestamp of tree: Wed, 27 Jun 2007 12:50:01 +0000 ccache version 2.4 [disabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -mtune=athlon64 -msse3 -O2 -pipe -falign-functions=64 -fforce-addr -ftracer -funit-at-a-time" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -mtune=athlon64 -msse3 -O2 -pipe -falign-functions=64 -fforce-addr -ftracer -funit-at-a-time" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict userfetch" GENTOO_MIRRORS="http://ftp.roedu.net/pub/mirrors/gentoo.org/ http://ftp.lug.ro/gentoo/ http://ftp.romnet.org/gentoo/ http://mirrors.evolva.ro/gentoo/ http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1" LINGUAS="en ro" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/cross-i586-pc-linux-gnu /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip X X509 a52 aac aalib acl acpi addbookmarks alias alsa amd64 amr aotuv apm arts autoreplace bash-completion bcp berkdb binfilter bitmap-fonts bjam bl boost branding bzip2 cairo cddb cdparanoia cdr chardet chroot cli connectionstatus contactnotes cpudetection cracklib crypt cups curl dbus dmi doc dri dts dv dvd dvdnav dvdr dvdread dynamic ecc encode epydoc erandom exif fam fbcon firefox flac fltk fontconfig ftp fusion gadu gdbm ggi gif gpm groupwise gstreamer gtk hal hardened highlight history hpn iconv icu idea idn ieee1394 ipv6 irc isdnlog ithreads java javascript jingle jpeg jpeg2k kde lcms ldap libcaca lm_sensors logrotate lua lzo mad mailwrapper md5sum midi mmx mng modplug mono mp2 mp3 mpeg mudflap musepack nas ncurses nforce2 nfs nls nowlistening nptl nptlonly nsplugin numeric nvidia objc objc++ objc-gc odbc odk offensive ogg openal openexr opengl openmp oss pcmcia pcre perl pic pmu png pnm pppd pyste python qt3 quicktime rar readline reflection rtc sametime sdl session slang slp sms sndfile sockets socks5 sound speex spell spl srt sse sse2 ssl statistics svg swig symlink sysfs tcl tcpd texteffect tga theora threads tidy tiff timidity tivo tk translator truetype truetype-fonts tta type1-fonts unicode usb userlocales v4l v4l2 vorbis wavpack webpresence winpopup wma x264 xanim xcomposite xinerama xml xorg xpm xscreensaver xvid xvmc yahoo zlib zoran" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ro" USERLAND="GNU" VIDEO_CARDS="fbdev nvidia vesa vga" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Unfortunately I personally have no amd64 box, but I've found this: http://www.mail-archive.com/classpath@gnu.org/msg14190.html and response: http://www.mail-archive.com/classpath@gnu.org/msg14191.html If you are willing to check if it works for you, let me know what the results are, please.
Could you give me a little hand. I am new to this ... 1) I think I must modify the /usr/share/java-config-2/launcher.bash, to add the -mx384M paramether. Am I right ? (I will use -mx512M on my machine instead) 2) If the above is correct in what variable/what line shall I put it ? 3) Is the paramether correct ? I thought it was -Xm512m Thank you for bearing with me...
I wouldn't touch anything outside sandboxed environment. Check out the classpath/classpath.build file, you should see an entry beginning with '<exec program="ecj"', try fiddling with commandline parameter, maybe that will help.
I have found the buildfile: .... /ikvm-0.34.0.2/classpath/classpath.build and modified the line: - <exec program="/usr/bin/ecj-3.2" commandline="-g -1.5 -nowarn -cp mscorlib.jar${pathsep}System.jar @allsources.lst" useruntimeengine="false" /> + <exec program="/usr/bin/ecj-3.2" commandline="-Xmx512M -g -1.5 -nowarn -cp mscorlib.jar${pathsep}System.jar @allsources.lst" useruntimeengine="false" /> with no success. As I found on: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm .... _______________________________________________________________ Ignored options (for compatibility with javac options) -J<option> pass option to the virtual machine -X<option> specify non-standard option. -Xemacs is not ignored. -X print non-standard options and exit -O optimize for execution time ________________________________________________________________ .... I think I failed with this approach. There must be another option to set memory usage, but it's not so obvious as the compile time parameter. How do they make that setup ? I ran some commands on my box: java-config -f : sun-jdk-1.5 java-config -L : The following VMs are available for generation-2: 1) Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2] 2) Blackdown JRE 1.4.2.03 [blackdown-jre-1.4.2] *) Sun JDK 1.5.0.11 [sun-jdk-1.5] java-config -v : java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) If my presumption is correct, during the compile Sun's Java Virtual Machine is used. Is there a way to set memory usage to this (as long as ecj ignores the setting) ?
This problem also exists on x86. It fails for me on two desktops and a laptop (basically all the machines I have gentoo on.) I have tried to build with all three versions of eclipse-ecj in the tree. A short term solution is to just use ikvm-bin but yesterday I had to download the zip file from sourceforge manually because portage couldn't fetch it for some reason. ebuild failure results below: [nant] /var/tmp/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build Buildfile: file:///var/tmp/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build Target framework: Mono 1.0 Profile Target(s) specified: IKVM.GNU.Classpath.dll jars: classes: [exec] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space [exec] at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Util.java:204) [exec] at org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Util.java:70) [exec] at org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:58) [exec] at org.eclipse.jdt.internal.compiler.batch.Main$2.acceptResult(Main.java:2506) [exec] at org.eclipse.jdt.internal.compiler.Compiler.handleInternalException(Compiler.java:502) [exec] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:430) [exec] at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2697) [exec] at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1272) [exec] at org.eclipse.jdt.internal.compiler.batch.Main.main(Main.java:1016) BUILD FAILED - 0 non-fatal error(s), 10 warning(s) /var/tmp/portage/dev-dotnet/ikvm-0.34.0.2/work/ikvm-0.34.0.2/classpath/classpath.build(27,10): External Program Failed: /usr/bin/ecj-3.2 (return code was 1) Total time: 19.1 seconds. BUILD FAILED Nested build failed. Refer to build log for exact reason. Total time: 25.4 seconds. !!! ERROR: dev-dotnet/ikvm-0.34.0.2 failed. Call stack: ebuild.sh, line 1637: Called dyn_compile ebuild.sh, line 983: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ikvm-0.34.0.2.ebuild, line 36: Called die !!! ikvm build failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/dev-dotnet/ikvm-0.34.0.2/temp/build.log'.
It looks like a common bug: http://permalink.gmane.org/gmane.comp.java.classpath.devel/9181 maybe our java team can help us here?
It's a problem with the new gnu classpath: http://developer.classpath.org/mediation/ClasspathDeveloperGuidelines Maybe the solution is to add classpath-0.95 as a depend (instead of building it in the same ebuild), that way classpath can just be built with javac and ikvm can be built with eclipse-ecj (does it have to be built that way?) Could the classpath build section be changed to use javac?
Created attachment 123343 [details] ikvm ebuild with javac instead of ecj Could you please try this ebuild and report your results here?
(In reply to comment #9) > Created an attachment (id=123343) [edit] > ikvm ebuild with javac instead of ecj > > Could you please try this ebuild and report your results here? > Still no go. I was able to get it to compile by editing /usr/bin/ecj-3.2 like this: - gjl_main="org.eclipse.jdt.internal.compiler.batch.Main" + gjl_main="-Xmx400m org.eclipse.jdt.internal.compiler.batch.Main" After that it compiles and installs perfectly. Not a very useful solution to the bigger problem though.
Created attachment 123352 [details] ikvm ebuild modified with javac heap increased to 256M This fixes it. Still using javac but giving it one more option -J-mx256M. This increases the heap size javac will use to 256M solving the classpath compile problem.
Sorry, I forgot to add the -J option (which was the reason for moving to javac, hence ecj/jikes simply ignore this). Could you please try this with some smaller values (192, 160, 128 and so on until build fails)? Thanks in advance!
(In reply to comment #12) > Sorry, I forgot to add the -J option (which was the reason for moving to javac, > hence ecj/jikes simply ignore this). Could you please try this with some > smaller values (192, 160, 128 and so on until build fails)? Thanks in advance! > 128 is too small. 160 seems to work fine. I think this problem may be solved...
So be it. Fixed in CVS, thanks for your input!
(In reply to comment #14) > So be it. Fixed in CVS, thanks for your input! > Any time.
