Hi, A number of people are having trouble running the (excellent) java editor IntelliJ IDEA (http://www.intellij.com/idea/download.jsp , don't forget the evaluation key), version 3.0 and later. See forum thread. Problems appeared apparently with glibc according to one poster (me). One possible cause is the fact that this java program is apparently compiled into an executable (or wrapped into a script) http://forums.gentoo.org/viewtopic.php?p=184127#184127 PS: feel free to mail me if I have to provide more info. --- Portage 2.0.46-r9 (default-x86-1.4, gcc-3.2.1, glibc-2.3.1-r2) ================================================================= System uname: 2.4.19-gentoo-r10 i686 Intel(R) Pentium(R) III Mobile CPU 1000MHz GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config:/usr/X11R6/lib/X11/xkb:/usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg gnome libg++ libwww mikmod mmx mpeg ncurses nls pdflib png qtmt quicktime spell truetype xml2 xmms xv zlib directfb alsa gdbm berkdb slang readline arts svga tcltk java guile X sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl mozilla cdr scanner" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe" CXXFLAGS="-march=pentium3 -O2 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
there's already 3.0.1 available did you try this ? is there any ebuild for this ?
yes, I tried 3.0.1 too, but even the installer gives those errors. So an evaluation key isn't even necessary to recreate this. addmitedly there is no ebuild for this, but it's one of the best java IDE's around, and it worked prior to the glibc upgrade, so it would be nice if the source of this could be found!
The .bin file from IntelliJ is an InstallAnywhere (or LaunchAnywhere?) shell script. It has code similar to following (perhaps to protect against an older RedHat bug). # glibc floating stack problem on Linux if [ `uname -s` = Linux ] then case `uname -r` in 2.[456]*) LD_ASSUME_KERNEL=2.2.5 export LD_ASSUME_KERNEL ;; esac fi Commenting out the LD_ASSUME_KERNEL and the line below it makes the script go further (yes, you can edit the .bin file), but then, while trying to expand the JRE, I run into problems. (This is from memory as my system is currently unbootable, and all I remember is what happened yesterday). The file size for /tmp/install.dir.?????/vm.tar.Z was exactly as specified in the script. However, both gzip and uncompress say that the file is not in compressed format. Somebody should try the above and tell me if you get the same behavior.
Another point to note is that this bug seems to be glibc related, as a lot of people had no problems before the glibc upgrade.
I commented out the LD_ASSUME_KERNEL line and got the same error as you. Maybe a checksum is calculated on the file ?
Hi Got the same problem with Lotud Domino 5.0.11. You can also edit out the "LD_ASSUME_KERNEL=2.2.5" part in the startup scriptof Domino. But then all hell brake lose. Normal stuff that worked prefiously inside domino freez domino, or domino just run out off memory. If I can remember corretly why they did it, it was something about java not working with the new 2.4.x kernel ??? I dont know. Any ideas ? Nar
Oops Found the reason why they did use the "LD_ASSUME_KERNEL=2.2.5" in domino. Here it is: # Set variable to work around issue with memory stack in glibc 2.2 # which Java cannot handle - once it can, then disable # this export LD_ASSUME_KERNEL=2.2.5 Hope it help Nar
I have made more progress. When commenting out the LD_ASSUME_KERNEL lines, I am presuming I did something to unknowingly change the characteristics of the .bin file, as it would no longer recognize the packages that it extracted using dd from itself (e.g., it would say vm.tar.Z is not in compressed format). Here's what I did. 1. cp idea-3.0.1v2.bin idea-3.0.1v2.bin.new 2. Edited idea-3.0.1v2.bin.new: 2a. comment out LD_ASSUME_KERNEL (lines 1991 and 1992) 2b. replace all dd if="$0" with dd if="idea-3.0.1v2.bin" (lines 468, 590, 607) 3. ./idea-3.0.1v2.bin.new Incidentally, I edited the file in vim and the diff between the two files showed that the original had "No newline at end of file". Maybe that had something to do with dd crapping out. After that I could run the installer without any problems. Now onto running the program itself. Edit files IntelliJ-IDEA-3.0.1/bin/idea and IntelliJ-IDEA-3.0.1/bin/inspection to comment out the LD_ASSUME_KERNEL and the export line right after it. Then run IntelliJ-IDEA-3.0.1/bin/idea and you will see the license screen. Somebody more intelligent than me needs to figure out the part about dd crapping out. Voila.
I can confirm that the solution as proposed in comment #8 works. As I understand it this is an IntelliJ bug, not a gentoo/glibc bug, so the java team can close this bug if they are satisfied with the solution and analysis of the problem. greetings Mike
Some people in the forum (http://forums.gentoo.org/viewtopic.php?t=27446) have been complaining about various problems, so just for completeness I will present the full details of my system. I edited with vim, (app-editors/vim-core-6.1-r4, app-editors/vim-6.1-r19). The filesizes were: 41222366 idea-3.0.1v2.bin 41222414 idea-3.0.1v2.bin.new I do have lib-compat (whether its significant or not): sys-libs/lib-compat-1.0-r2 * sys-libs/lib-compat-1.1 * my jdk version is: dev-java/sun-jdk-1.4.1.01 and finally "emerge info" (I run ACCEPT_KEYWORDS="x86 ~x86") : Portage 2.0.46-r9 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r3) ================================================================= System uname: 2.4.20-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz GENTOO_MIRRORS="http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/portage.local" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png qtmt quicktime spell truetype xml2 xmms xv zlib gtkhtml alsa gdbm berkdb slang readline arts tetex bonobo svga tcltk java guile mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla cdr scanner xfs" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe -s -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math" CXXFLAGS="-march=pentium4 -O3 -pipe -s -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
I have found a way to edit the file in place by using hexedit (app-editors/hexedit-1.2.2). Hence no more messing around with changing the args to "dd". Here's the procedure: 1. Backup the original file 2. hexedit idea-3.0.1v2.bin 2a. Press TAB (this will take you to the ASCII side of things) 2b. Press / (this will prompt you for a search term) 2c. Type LD_ASSUME_KERNEL and ENTER (this will find the first ASCII occurence of LD_ASSUME_KERNEL) 2d. Type a # (you will get #D_ASSUME_KERNEL) 2e. Find the next line and make export look like #export 2f. CTRL-X to exit and save changes. 3. ./idea-3.0.1v2.bin And the installer should now run in place. Reminder: After the installer is done, you still need to edit bin/idea and bin/inspection in the final install dir, the old-fashioned way to comment out the LD_ASSUME_KERNEL and the following export line.
My bad, in comment 11, 2e should say: 2e. Find the next line and make export look like #xport (Notice the missing e before xport)
I have been able to install and run IntelliJ without editing any files. My guess is that my emerge of lib-compat fixed the lib compatibility problems :) Can someone confirm this ?
I sort of remember doing an install not too long ago which didn't involve editing any files either. Time to close this one, I guess.
looks closeable to me maybe i will add an ebuild for this soon
