AMD64 installation problems
Can anybody point me to any information how to make Pallada install on AMD64 platform on Linux?
Right now it is throwing errors in the installation process. I tryed first tar.gz, but I had an error during untar.
Thank you in advance
Yourek
Please sign in to leave a comment.
If you do get IDEA to work please post your results. I am interested in this as well.
An error during untar probably isn't related to you being on AMD64. You should be sure to use GNU tar.
This is what I have. From your letter it looks good enough...
Now, when I try:
I tryed on two diffrent downloads... This same efect, so this is very unlikely that it is problem with my download. Just for additional informations the idea2018-linux_jre.tar.gz untars just fine.
As you may see, I am stoped in the blocks ;)
Now, if I try with the idea2178.bin, I have exactly this:
Any help will be very welcomed.
Yourek
That lone zero block isn't an error message as far as I can tell. I ignore it, and IDEA runs fine for me.
As for the .bin installer, it needs to be updated to stop using deprecated options for head and/or tail (tail -1 should be replaced with tail -n 1 in the script). There's nothing you can do about that, it's something IntelliJ should change.
Jerzy Puchala wrote:
It works fine - ignore the 'lone block' error, it isn't fatal or
anything. The tar itself is fine.
I'm running it on top of Blackdown's 1.4.2_rc1 native-AMD64 JDK, and
you'll have to add -Didea.no.jdk.check=true to the JVM_ARGS variable (in
the idea.sh script)
No problems so far. Nice and snappy :)
Regards,
Edwin
Jerzy Puchala wrote:
Forgot to add - I'm using the tar.gz download without the IntelliJ
supplied JRE. 32-bit JRE's dont work, and that's the cause of the
'locale not supported' errors you're getting. Just switch to an AMD64
jdk. Blackdowns is fine, Sun's 1.5beta (sorry, Suns 5.0beta) works as well.
Regards,
Edwin
hi,
whats the performence with the 64bit JDK anything better than 32bit ???
Ralf Kraus wrote:
Yeah, compiling is nice and snappy. Don't have hard figures, though -
the harddrives in this machine are a lot faster, more RAM - I'm sure
that makes a big difference, too.
I'll see if I can find some benchmark tools.
CU,
Edwin
Try setting your locale to C before running the installer:
LC_ALL=C sh idea-2178.bin
I've just tried build 2226, and found that it was looking for ]]>/bin/java
I've been rude and just symbolically linked the Blackdown jre into IDEA's folder, to avoid synch issues (I have had 2 variants of Java3D by mistake in the past...)
So, linked bin/amd64 to bin, fixed that. Then I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/IntelliJ/IDEA-2226/bin/libbreakgen.so:... : cannot open shared library
Now, libbreakgen.so exists in the place it says it is looking, viz:
ls -l /opt/IntelliJ/IDEA-2226/bin/libbreakgen.so
-rw-r
r1 bin bin 6185 Jul 23 19:06 /opt/IntelliJ/IDEA-2226/bin/libbreakgen.soAny ideas? I'm using Blackdown's AMD64 JDK (1.4.2 rc1)
Cheers,
Ian
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/your/path/to/idea/bin
Hi Marcus,
Thanks for the thought - but no dice. Will the .so work within a 64-bit varaint of Linux? i.e. will it barf if asked to load a 32-bit lib...
If my guess is true, then the error message "file not found" is kinda curious, I was expected an architecture complaint...
Anyone else had this wierdness? Does the run/debug work OK for them?
Hmmn...
Ian
Hm, try to remove the .so files. IDEA supposedly doesn't need them, but uses them if they're available.
Ian Grimstead wrote:
In general, this often works - if you have the 32bit compatibility glibc
libs installed and you're running a 32 bit program. In this case it
won't since you're running a 64 bit JDK...
Yes, it does work for me, and stranger still, I haven't seen the message
you mention at all...
Anyway, my understanding of it was that the libbreakgen.so is for
creating thread dumps. So it shouldn't be vital. Ofcourse, I may be
completely wrong :)
regards,
Edwin
Edwin van Ouwerkerk Moria wrote:
>> Thanks for the thought - but no dice. Will the .so work within a
>> 64-bit varaint of Linux? i.e. will it barf if asked to load a 32-bit
>> lib...
>> Anyone else had this wierdness? Does the run/debug work OK for them?
You are completely right! Except thread dump generation in run
everything work fine for me with Sun JDK.
On the other hand I wasn't able to make Blackdown for AMD64 work in
debug mode. Were you and if you were how?
Thanks,
IK
Igor Kuralenok (JetBrains) wrote:
No, not reliably - I think once or twice, but it usually just sits there
waiting for the debugger to connect. (And eats up a big chunk of memory)
The 1.4.2 fcs should be out 'any day now', then I'll try again. In the
meanwhile, using Sun's JDK (1.5 / 5.0 - whatever) works quite well,
though, so I switched to that.
Btw - in both I had to make a symlink in the /home directory to an (non-existent) 'amd64' directory. Don't know what's up with that, but IDEA seems to insist on running /bin/amd64/java, instead of ]]>/bin/java . Happens with Sun & blackdown JDKs.
Regards,
Edwin
I get the same on Linux Ubuntu Hoary 64 bit:
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
Launching installer...
current locale is not supported in X11, locale is set to CX locale modifiers are not supported, using defaultInvocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)
Stack Trace:
java.lang.InternalError: Current locale is not supported
at sun.awt.motif.MWindowPeer.pSetTitle(Native Method)
at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:97)
at sun.awt.motif.MFramePeer.]]>(MFramePeer.java:58)
at sun.awt.motif.MToolkit.createFrame(MToolkit.java:209)
at java.awt.Frame.addNotify(Frame.java:472)
at com.zerog.ia.installer.Main.d(DashoA8113)
at com.zerog.ia.installer.Main.a(DashoA8113)
at com.zerog.ia.installer.Main.main(DashoA8113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.zerog.lax.LAX.launch(DashoA8113)
at com.zerog.lax.LAX.main(DashoA8113)
GUI-
To make it work:
1. download and install your favourite version of JVM (I had success with SUN JDK 1.4, 1.5 - did not try others).
2. download EAP version of IDEA
3. in my case I decided to install both in /opt , so I have
after this:
next edit the
file.
Add the " -Didea.no.jdk.check=true" into JVM_ARGS variable, and add also line:
after all CLASSPATH lines.
(in the last build I had to also remove "-Xrunyjpagent:port=10100" from JVM_ARGS, you have to try).
In some early builds there was a problem that idea.sh was not executable. Just take a look - it is OK for some time.
When I untar idea I use
so I preserve rights. Don't worry about
Its all I do.
I hope it will help.