It’s hard to believe that 32/64-bit compatibility is still an issue in this day an age. I’d hoped it would be plain sailing by now.
But no.
I use Webex at work, and at some point it and/or java stopped working. I kind of lost track of what I’d done before, but decided I wanted the “pure” solution or none at all (64-bit OS, therefore 64-bit firefox and 64-bit java). I failed to get it working, so resorted to running it in a Windows 7 VM in VirtualBox (works perfectly, of course).
I decided to spend a little more time on it, and with the latest java and firefox (jre-1.7.0_40 and firefox-24.0-1), the applet side of things “Just Worked”, i.e.:
http://java.com/en/download/installed.jsp?detect=jre&try=1 reports “Congratulations! You have the recommended Java installed (Version 7 Update 40).”
To get this far, install the latest jre RPM (http://www.java.com/en/download/linux_manual.jsp?locale=en)
# rpm -Uvh jre-7u40-linux-x64.rpm # /usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000 # /usr/sbin/alternatives --config java There is 2 program that provides 'java'. Selection Command ----------------------------------------------- *+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.2.0.fc19.x86_64/jre/bin/java 2 /usr/java/default/bin/java Enter to keep the current selection[+], or type selection number: 2
Symlink the java plugin to somewhere appropriate (I chose my home directory):
$ ln -s /usr/java/default/lib/amd64/libnpjp2.so ~/.mozilla/plugins/
And restart firefox.
However, starting a Webex would work to a point, but I couldn’t see anything I entered into the chat box, or any response (although both show up on a working client at the other “end”).
I’d got the java console running and googled around on some of the errors I was seeing.
This got me this page:
http://www.emsperformance.net/2013/03/25/making-webex-work-on-64bit-fedora-core-18/
This implied that installing the 64-bit version of the pangox-compat RPM would help. I already had that. In desperation, I tried installing the i686 version, too. No improvement in symptoms.
After poking around some more, using this error:
Loading native DBR... java.lang.UnsatisfiedLinkError: /home/jwrigley/.webex/1224/libdbr.so: /home/jwrigley/.webex/1224/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch
I found that there are a bunch of files pulled down by the applet (I presume?) into ~/.webex/1224/, which are 32-bit (I don’t know if the number, here 1224, differs on other systems).
$ file .webex/1224/*.so .webex/1224/atascli2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped .webex/1224/atascli.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped .webex/1224/atgzip.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped ...
More googling brought little hope. The consensus appeared to be that the only solution is to run 32-bit firefox and java. *spit*
Tenacity, or pigheadedness, forced me to have one more try.
As described in the link above, I straced the java process once I’d started a conference. This opened a lot of threads.
I noticed that the strace process would report, when I clicked “Share My Desktop”, something like this:
Process 1004 attached [ Process PID=1004 runs in 32 bit mode. ]
That saved me some time in grepping, as I opened the strace log for that process and right at the bottom:
15:16:16 writev(2, [{"/home/jwrigley/.webex/1224/atasj"..., 34}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libXmu.so.6", 11}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10) = 145
I had libXmu.so.6 in /usr/lib64, so I figured it couldn’t hurt to try installing the 32-bit version:
# yum install libXmu.i686
Tried again, and still not working, but the new thread had a different error, this time libXt.
I followed this cycle a couple of times, installing 32-bit versions of libXt, libXmu and gtk2 (for libgtk-x11-2.0.so.0), and lo! I got a popup telling me I was sharing my desktop. Unfortunately, I couldn’t see my desktop on the other client, but when I shared that desktop, I could see it on my local machine.
The packages I installed, as a one-liner:
# yum install pangox-compat.i686 libXt.i686 libXmu.i686 gtk2.i686
(the last one pulls down quite a few dependencies.
The problem with the chat appears to have come along with the newer java, as there are claims that it’s fixed by rolling back. The associated error/traceback is:
chat component version = 2011.01.29.1101 Resource: atlchat Resource: atlchat_en Resource: atlchat_en_US Exception in thread "AWT-EventQueue-3" java.lang.IllegalStateException: This function should be called while holding treeLock at java.awt.Component.checkTreeLock(Unknown Source) at java.awt.Container.validateTree(Unknown Source) at ChatControlPane.access$100(ChatControlPane.java:61) at ChatControlPane$1$1.run(ChatControlPane.java:120) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$200(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
So, only a partial fix, but at least I can view somebody else’s shared desktop from the comfort of my own browser, which is about 90% of my use-case.