Java sucks :) yea, its plugin isnt working on amd64 opera. So few steps hot to make it work in dirty way. (dunno if ill brake something, im just using java for that plugin not anything more!) checked with opera 10.00_pre4340 and sun-jdk-1.6.0.13 Reproducible: Always Steps to Reproduce: 1.ln -s /opt/sun-jdk-1.6.0.13/jre/lib/ /opt/sun-jdk-1.6.0.13/jre/lib/amd64/ #this will make opera find jbjwm.so 2.ln -s /opt/sun-jdk-1.6.0.13/jre/lib/amd64/server/libjvm.so /opt/sun-jdk-1.6.0.13/jre/lib/amd64/ #same here 3. go to tools> preferences >content> enable java, click java options and set path to /opt/sun-jdk-1.6.0.13/jre/lib/amd64/ then click volidate #standard .gentoo/java-config will not work or setting it to /opt/sun-jdk-1.6.0.13 where points that link. Actual Results: We can se ugly dancing suns pupet on http://www.java.com/en/download/help/testvm.xml
i would forget. Step 4 restart opera! Without restarting it will not work.
How does Opera run Java, if its via Sun's java plugin 64 bit is only supported for Firefox 3.
Yes its via sun's java plugin for 64 bit system. They say that plugin is only suppoerted on FF3 but konqueror runs it to without any problem (without doing any dirty stuff). Plugin is plugin. Opera have just problem with paths. java-config-2 -L The following VMs are available for generation-2: *) Sun JDK 1.6.0.13 [sun-jdk-1.6]
(In reply to comment #3) > konqueror runs it to without any problem (without doing > any dirty stuff). Plugin is plugin. Opera have just problem with paths. No konqueror doesn't use the plugin, it runs a JVM process.
$ ldd $(find ~/.gentoo/java-config-2/current-user-vm/ -iname '*libjava.so') linux-vdso.so.1 => (0x00007fff99ffe000) libjvm.so => not found libverify.so => /home/alistair/.gentoo/java-config-2/current-user-vm/jre/lib/amd64/libverify.so (0x00007f4c91cef000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f4c91ad7000) libdl.so.2 => /lib/libdl.so.2 (0x00007f4c918d3000) libc.so.6 => /lib/libc.so.6 (0x00007f4c9157d000) /lib64/ld-linux-x86-64.so.2 (0x00007f4c91f5b000) libjvm.so => not found and then $ LD_LIBRARY_PATH="/opt/sun-jdk-1.6.0.14_beta6/jre/lib/amd64/server/" opera and boom, we have a java applet clock here http://www.opera.com/media/applets/clock/ Sadly this is systematic of a far larger problem. A completely java one.
I should also note, that I set up the opera to point to the java plugin at /opt/sun-jdk-1.6.0.14_beta6/jre/lib/amd64/ sorry for the bugspam.
Ok, i was all wrong, but my action made good reaction. Thx Alistair for less dirty way. Can you say are java applets crashing when using them on more than one window (not tabs, file>new window) with u14b6?
jack@jacktop ~ $ opera --debugjava ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded: ignored. opera: X Shared memory extension is not available. ZPixmap not supported opera: [java] failed to load libawt.so: libawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load libjawt.so: libjawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load a suitable awt library. Java will not work. which: no soundwrapper in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin) jack@jacktop ~ $ LD_LIBRARY_PATH="/opt/sun-jdk-1.6.0.13/jre/lib/amd64/server/" opera --debugjava ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded: ignored. opera: X Shared memory extension is not available. ZPixmap not supported opera: [java] failed to load libawt.so: libawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load libjawt.so: libjawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load a suitable awt library. Java will not work. which: no soundwrapper in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin)
my comment #8 is missing the first part. i was going to write: i still have problems with opera and java (64 bit) i am using opera-9.64 and sun-jre-1.6.0.13 and i get the following error: opera --debugjava ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded: ignored. opera: X Shared memory extension is not available. ZPixmap not supported opera: [java] failed to load libawt.so: libawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load libjawt.so: libjawt.so: cannot open shared object file: No such file or directory opera: [java] failed to load a suitable awt library. Java will not work. which: no soundwrapper in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2:/usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin)
Created attachment 197452 [details, diff] Add 'server' subdir to LD_LIBRARY_PATH
With above patch applied to /usr/bin/opera, it finds the library easily. (In reply to comment #2) > How does Opera run Java, if its via Sun's java plugin 64 bit is only supported > for Firefox 3. Running applets via plugin is only dirty hack. Opera instead of using such hacks uses the JRE libraries.
Created attachment 199601 [details, diff] Patch adding necessary directory into install.sh What's interesting ${S}/opera script has javapath correctly updated while ${S}/install.sh does not. Uploading patch to update it.
Created attachment 199602 [details, diff] Diff to add the patch into ebuild
Should applying the ebuild patch (and having the other patch in ${FILESDIR}) make java working on opera-10.00_rc4570 without any additional steps? It doesn't work for me. I get the following when launching opera: $ opera ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded: ignored. opera: libjava.so: cannot open shared object file: No such file or directory This stuff (once it's working correctly) should definitely be integrated into the tree.
(In reply to comment #14) > Should applying the ebuild patch (and having the other patch in ${FILESDIR}) > make java working on opera-10.00_rc4570 without any additional steps? You need to set correct java directory inside Opera too, and then restart Opera. It'd be a lot easier if eselect-java (or sth related) could create some symlink to current java version so that such symlink could be used within Opera. Currently you have to update the javadir on each java update.
(In reply to comment #15) > You need to set correct java directory inside Opera too, and then restart > Opera. > > It'd be a lot easier if eselect-java (or sth related) could create some symlink > to current java version so that such symlink could be used within Opera. > Currently you have to update the javadir on each java update. I did, and the validation button on the Opera preferences window says the path is correct. Still no go for the test at: http://www.java.com/en/download/help/testvm.xml – says “Something is wrong. Java is not working.”
(In reply to comment #15) > You need to set correct java directory inside Opera too, and then restart > Opera. > > It'd be a lot easier if eselect-java (or sth related) could create some symlink > to current java version so that such symlink could be used within Opera. > Currently you have to update the javadir on each java update. Ok, I was wrong two times. First, you should be able to leave out java path in Opera empty, and then the wrapper should be able to find it using environment vars. But that is broken and works only for x86, I'll supply a patch for that in a while. Second, eselect java-vm creates symlink to selected JRE/JDK, and you can find it in /etc/java-config-2/current-system-vm. (In reply to comment #16) > I did, and the validation button on the Opera preferences window says the path > is correct. Still no go for the test at: > http://www.java.com/en/download/help/testvm.xml – says “Something is wrong. > Java is not working.” Did you restart Opera and turned on java support again (F12, enable java) — Opera disables it totally each time it isn't able to run java.
Created attachment 202398 [details, diff] Look for amd64 JRE/JDK on amd64 And that's another patch, it makes Opera wrapper script look for libjava.so in 'amd64' on x86_64 Linux and BSDs (I've tested it only on Linux). With this patch, user should no longer have to provide Java path on amd64 in Opera as Opera will be able to find the current VM if the path isn't set. Note that after applying this patch, 64-bit Opera won't find 32-bit Java libraries automagically anymore.
Created attachment 202400 [details, diff] Look for amd64 JRE/JDK on amd64 (fixed indent) Fixed to match upstream indent style.
Created attachment 202401 [details, diff] Diff to add patches into the ebuild
(In reply to comment #20) > Created an attachment (id=202401) [edit] > Diff to add patches into the ebuild I tried your latest modifications and it still doesn't work. The „Java path” field now validates correctly with the default path; about:plugins shows: Java(TM) Plug-in 1.6.0_16 /usr/lib64/nsbrowser/plugins/javaplugin.so But java applets won't run. Obviously I did turn on „[x] Enable Java” in preferences → advanced → content (otherwise I wouldn't be able to validate Java path).
When I launch an Opera instance [ ] Enable Java is deselected and I have to re-enable it manually each time. As to debugging I only get the following: $ opera --debugjava opera: [Java] Adding '/etc/java-config-2/current-system-vm/jre/lib/plugin.jar' to classpath. Runtime link error - it appears that libXt got loaded before libXm, which is not allowed.
(In reply to comment #21) > Java(TM) Plug-in 1.6.0_16 > /usr/lib64/nsbrowser/plugins/javaplugin.so Forget about the plugin, Opera doesn't require nor use it. (In reply to comment #22) > Runtime link error - it appears that libXt got loaded before libXm, > which is not allowed. Do you have any specific LD_PRELOAD or something?
No, definitely not. Any other debug info you'd like me to paste in?
(In reply to comment #24) > No, definitely not. Any other debug info you'd like me to paste in? I don't really have an idea what could it be. I've tested Qt4-shared, Qt3-shared & Qt4-bundled, and java works in all of them. Which xorg version do you have?
it's funny, but if you take opera tarball from distfiles, unpack it (in user's home dir for example), and run ./opera (without running install.sh first) java plugin works out of the box. however, the same opera installed with gentoo's ebuild fails to load libjvm.so, as reported above. tested on: opera-10.00 & jdk-1.6.0_u16.
(In reply to comment #26) > it's funny, but if you take opera tarball from distfiles, unpack it (in user's > home dir for example), and run ./opera (without running install.sh first) java > plugin works out of the box. however, the same opera installed with gentoo's > ebuild fails to load libjvm.so, as reported above. As I mentioned before, we're using install.sh to generate wrapper script instead of using included one, and the template inside install.sh is outdated.
OK, so maybe some changes of ours to the wrapper script /usr/bin/opera are breaking Java support?
(In reply to comment #28) > OK, so maybe some changes of ours to the wrapper script /usr/bin/opera are > breaking Java support? No, this is upstream bug where template inside install.sh is outdated. I've reported both of issues related to the bug as DSK-262808 & DSK-262815.
> > No, definitely not. Any other debug info you'd like me to paste in? > > I don't really have an idea what could it be. I've tested Qt4-shared, > Qt3-shared & Qt4-bundled, and java works in all of them. > > Which xorg version do you have? x11-base/xorg-x11-7.4 x11-base/xorg-server-1.6.3 I don't suppose this should make a difference though.
I tried your two patches on the final release of opera-10.00 (build 4585 without Unite) and also moved from qt-static (which I had when making my previous comments) to qt-shared (because of another unrelated bug in the static version). When I try loading a page with an applet now, the whole program just bombs out and I'm left with the crash report tool. So much for java (and flash for that matter which *never* seems to work quite correctly even if it does at all)...
@Antek: One more question (I think I missed that one): which JRE/JDK are you using?
(In reply to comment #32) > @Antek: One more question (I think I missed that one): which JRE/JDK are you > using? dev-java/sun-jdk, I tried both 1.6.0.15 and 1.6.0.16.
Here's the crash as seen from the shell. $ opera Warning: Cannot convert string "MetaCtrl<Key>Insert" to type VirtualBinding opera [crash logging]: CRASH!! /opt/opera/lib/opera/10.00/opera got signal SIGSEGV at address 7FF158E6F7DF Log was created here: /var/tmp/crash20090903192713.txt (operapluginwrapper-native:21558): Gdk-WARNING **: GdkWindow 0x10000bd unexpectedly destroyed (operapluginwrapper-native:21558): Gdk-WARNING **: GdkWindow 0x10000bc unexpectedly destroyed (operapluginwrapper-native:21558): Gdk-WARNING **: GdkWindow 0x10000bb unexpectedly destroyed (operapluginwrapper-native:21558): Gdk-WARNING **: GdkWindow 0x10000b8 unexpectedly destroyed The program 'operapluginwrapper-native' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 23702 error_code 3 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Killed
*** Bug 275423 has been marked as a duplicate of this bug. ***
I managed to get http://www.opera.com/media/applets/clock/ show the applet by symlinking sudo ln -s /opt/sun-jdk-1.6.0.17/jre/lib/amd64/server /opt/sun-jdk-1.6.0.17/jre/lib/amd64/client and setting the java path in Opera to /opt/sun-jdk-1.6.0.17/jre/lib/amd64 . I guess opera always tries to use the client vm which does not exist for amd64.
if you have sun-jdk, just add an /etc/cron.daily/opera-env containing #!/bin/sh echo LDPATH="`find /opt/*jdk* \( -name libjvm.so -o -name libawt.so \) \ -exec dirname \{\} \; | sort -r | uniq | tr "\n" ":"`" > /etc/env.d/99xmw env-update This will find the currently installed version of jdk and add the correct /opt/sun-jdk-.../jre/lib/amd64/server/ dir to ld.so.conf/cache. This is more reliable in case of jdk updates as manual created env.d files.
On amd64 java do not work for me in opera-10.53_pre6330 despite java plugin seems to be properly loaded (it is visible on opera plugin list). When i try to use this plugin opera says it's not loaded (sic!) I have jre-1.6.0. Someone knows the problem? And maybe also solution...
(In reply to comment #38) > Someone knows the problem? And maybe also solution... Can you please provide any test-URL for other to reproduce the problem?
Ew, this bug is becoming more and more messy. It's originally about versions up to 10.10, which do NOT use the Java plugin but use Java directly (which is a problem if the path isn't properly set). >=10.50 does use the Java plugin but it isn't working properly yet. According to the latest information[1], this is a known issue, which makes comment #38 irrelevant to this bug report. (Filing a new bug report won't help either - there's nothing I can do about it and Opera developers are already aware of the issue.) This bug report will likely be fixed when something >10.50 finally goes final. [1] http://my.opera.com/desktopteam/blog/2010/05/05/startup-crashes-be-gone
it really seems, this is upstream problem, i didn't realize this, sorry for messing ...
Could anyone test whether Java support now works out of the box on amd64?
(In reply to comment #42) > Could anyone test whether Java support now works out of the box on amd64? > Works fine and fully out of the box. Even better than in firefox.
Seems to be working fine!
Thanks.
