| Summary: | IntelliJ IDEA stopped running with glibc 3.2 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mike Rosseel <Mike.Rosseel> |
| Component: | Current packages | Assignee: | Todd Berman (RETIRED) <tberman> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | corporate_gadfly, mholzer |
| Priority: | High | ||
| Version: | 1.4_rc2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Mike Rosseel
2003-01-25 10:57:48 UTC
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 |
