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

18 comments
Comment actions Permalink

If you do get IDEA to work please post your results. I am interested in this as well.

0
Comment actions Permalink

An error during untar probably isn't related to you being on AMD64. You should be sure to use GNU tar.

0
Comment actions Permalink

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:

(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-
]]>


Any help will be very welcomed.

Yourek

0
Comment actions Permalink

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.

0
Comment actions Permalink

Jerzy Puchala wrote:

Can anybody point me to any information how to make Pallada install
on AMD64 platform on Linux?


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

0
Comment actions Permalink

Jerzy Puchala wrote:

Can anybody point me to any information how to make Pallada install
on AMD64 platform on Linux?


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

0
Comment actions Permalink

hi,

whats the performence with the 64bit JDK anything better than 32bit ???

0
Comment actions Permalink

Ralf Kraus wrote:

whats the performence with the 64bit JDK anything better than 32bit ???


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

0
Comment actions Permalink

Try setting your locale to C before running the installer:

LC_ALL=C sh idea-2178.bin

0
Comment actions Permalink

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-rr 1 bin bin 6185 Jul 23 19:06 /opt/IntelliJ/IDEA-2226/bin/libbreakgen.so

Any ideas? I'm using Blackdown's AMD64 JDK (1.4.2 rc1)

Cheers,

Ian

0
Comment actions Permalink

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/your/path/to/idea/bin

0
Comment actions Permalink

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

0
Comment actions Permalink

Hm, try to remove the .so files. IDEA supposedly doesn't need them, but uses them if they're available.

0
Comment actions Permalink

Ian Grimstead 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...


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...

Anyone else had this wierdness? Does the run/debug work OK for them?


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

0
Comment actions Permalink

Edwin van Ouwerkerk Moria wrote:

Ian Grimstead 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...


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...

>> Anyone else had this wierdness? Does the run/debug work OK for them?


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 :)

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

0
Comment actions Permalink

Igor Kuralenok (JetBrains) wrote:

On the other hand I wasn't able to make Blackdown for AMD64 work in
debug mode. Were you and if you were how?


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

0
Comment actions Permalink

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-

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.