Webex on 64-bit Fedora 19

By | 23rd September 2013

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.