Making webex work on 64bit Fedora Core 18

Webex on 64 bit linux

I’ve seen in many places people having issues with the webex on 64bit systems.
Some reported that installing 32 bit version of firefox, 32 bit version of java and running webex under this 32 bit version environment works for them.

In my case it didn’t work, or rather most important features of webex didn’t work.
I could not share my screen or see other’s screen.
When I was sharing my screen – other people just saw a green background.
And when others were sharing – I saw nothing at all, except webex main window.
I had a fairly fresh installation of Fedora Core 18 64 bit so I imagine that most of people who will install Fedora Core 18 will have roughly the same set of packages.

Here is how I made webex work and not just in 32 bit mode, but in 64 bit as well!
So as a first step let’s make sure that we have strace package

yum install strace

Now we can trace processes, but webex is a multithreaded application, so to trace it properly we need to include option -ff. With this option it will track new opened threads and will create a separate trace file for each of these threads.
Without this option all we will get in the output will be something similar to this

Process 12610 attached
futex(0x7f100e64c9d0, FUTEX_WAIT, 12613, NULL

Which will sit there for the duration of the webex session.

In the below command I’m tracing webex and outputting trace information to files webex.$pid
where $pid is each individual thread process id.

strace -ff -t -p `ps -ef|grep -v grep|grep java|awk '{ print $2 }'` -o webex

Above command assumes that we don’t have any other java stuff running on the system at the time of tracing, otherwise we might need to adjust grep statement.

So let’s start our webex session, in terminal run tracing command and wait till we have webex main window open.
Now let’s close this webex window.
And it’s time to examine our trace files.

Let’s search for open system call

grep open webex.????

We will see lots of output.
This output means that different threads are searching for shared libraries on the system (or some other files as well).
Normally library search process goes like this and when library is finally found on the system it returs some file descriptor like on line 3

webex.8406:14:58:18 open("/usr/lib/firefox/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/firefox/plugins/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/lib/", O_RDONLY|O_CLOEXEC) = 3

Examining output I noticed that one of the libraries was not found and it seems like it also produced error message on line 8

webex.8406:14:58:18 open("/usr/lib/tls/i686/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/tls/sse2/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/tls/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/i686/sse2/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/i686/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/sse2/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 open("/usr/lib/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
webex.8406:14:58:18 writev(2, [{"/home/dmitry/.webex/1124/atasjni", 32}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"", 18}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10) = 150

Luckily this error message was at the very bottom of the output, so I didn’t have to go throgh all 1047 lines returned to me by grep command.

My next step was to find out what package this shared library belongs to

yum provides "*/"

And then installing it.

yum install pangox-compat-0.0.2-1.fc18.x86_64

Above I’m installing 64 bit version since my system is 64 bit, but if you are on a 32 bit OS or using 32 bit workaround – then just install 32 bit version of it.

yum install pangox-compat-0.0.2-1.fc18.i686

After installing above package my webex started to work like it was intended to.
I can share my screen and I can see while others sharing.
And it’s all on 64 bit – my firefox is 64bit and my java is 64 bit.

This entry was posted in Linux, RedHat and tagged , , . Bookmark the permalink.

13 Responses to Making webex work on 64bit Fedora Core 18

  1. Rodolfo says:

    great … mostly because you show me how to intercepts the system calls… :-)… great-…. , related to webex…, just a question…, did you enabled the webex audio “call using this cumputer” adding the missing library ??

    Thanks & Best,

    • admin says:

      I don’t know about audio, since company I work for doesn’t use webex audio conf.
      But my guess is that webex audio call won’t work on 64bit.

      There are several libraries that are provided by webex and they get loaded during your first webex start.
      For instance on my system they are under $HOME/.webex/1124

      ls -1 *.so

      When starting webex under 64 bit environment with enabled java console I can see these exeptions. I’m not sure what those libraries are, but if they are responsible for audio – then you would have to setup 32 bit environment and start webex from under it.

      java.lang.UnsatisfiedLinkError: /home/dmitry/.webex/1124/ /home/dmitry/.webex/1124/ wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
      Loading native DBR...
      java.lang.UnsatisfiedLinkError: /home/dmitry/.webex/1124/ /home/dmitry/.webex/1124/ wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

      Also make sure that you don’t use Java1.7.x, cause webex chat won’t work under it.
      There will be numerous errors

      Exception in thread "AWT-EventQueue-3" java.lang.IllegalStateException: This function should be called while holding treeLock

      Which is fixed by falling back to java 1.6.x
      In my case webex chat didn’t work under jre1.7.0_13 (64 bit and 32 bit) but failing back to jre1.6.0_23 made chat work.

  2. Pradeep K. Shima says:

    Thanks a ton !
    Your debugging technique helped me get webex running on 64 bit fedora 18 as well.
    Though the libraries I had missing were 32 bit ones. Installing those fixed it all.

    • Sodo says:

      Did you get audio working for the WebEx client under Fedora 18? If so, how did you do it?

      I’m on F18, 3.10.12-100.fc18.x86_64 64-bit and haven’t been able to get the audio portion to work. I’m using 64-bit firefox and used Dmitry’s strace technique, but don’t see any missing libs as smoking guns.


      • admin says:

        No, I didn’t cause my company doesn’t use webex audio conferencing, so we use webex only for screen sharing and audio goes via different provider.
        Are you on 64 or 32 bit?
        If you are on 32 bit – I think it should work as is.
        But if you are on 64 bit – I think chances are slim.
        audio libraries are distributed by webex, so when you start webex you will see that webex will bring some libraries

        In my case I can see message in the console

        java.lang.UnsatisfiedLinkError: /home/dmitry/.webex/1124/ /home/dmitry/.webex/1124/ wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

        Which means that library was created for 32 bit and won’t be loaded by 64 bit jre.
        It’s not something you can install from repos, it’s just bundled with webex

        I think for 64bit you can setup:
        32 bit version of firefox
        32 bit version of jre
        make 32 bit version of firefox aware of
        configure your environment to start 32bit firefox

        In fact I do just that when I need to work with some very old java applets that require jre 1.5.x 32 bit.

  3. dude says:

    don’t underestimate power of awk:
    ps -ef|awk ‘/java/ && !/grep/ { print $2 }’
    faster and easier

  4. Dilip says:

    Thanks for the guide. It helped me fix desktop sharing issue on fedora 19.

    32bit was missing in my system.

    $ ls -l /usr/lib/
    ls: cannot access /usr/lib/ No such file or directory
    $ sudo yum reinstall mesa-libEGL.i686

  5. grog says:

    Fabulous, this helped me fix my suse 11.4 & 12.2 issue. Where it was libXmu-devel-32bit missing.


  6. rogerrut says:

    This article was a great help and a time saver to resolve the webex issues on 64bit Linux systems. Using strace in combination with grep quickly pointed out which libraries were missing. Unfortunately each linux distro is different. I run OpenSuSE 12.3 and the missing libraries were libXmu and libpangox. After adding these libs WebEx sharing worked like a charm.

    Great contribution!

  7. Robin says:

    You are amazing! Thanks for this life saving article 🙂

  8. David Williams says:

    Thank you so much. At some point WebEx screen sharing had quit working from my Slackware machine. I’d basically given up, but searched again and found this.

    For the benefit of any Slackware users reading, I am running a multilib 14.1 installation. I found the same pangox-compat library missing. The steps I took to get this working were:

    1) Build/install pangox-compat from Slackbuilds to get the 64-bit library.
    2) Build the 32-bit package and run convertpkg-compat32 on it.
    3) Install the compat32 package.

    All good now.

    Thanks again!

  9. Tomislav says:

    Hi, Dmitry, thanks for the guide. I’m trying to follow the procedure you described on my Ubuntu 14.04.5 machine (Firefox 51.0.1 64-bit, IcedTea-Web 1.5.3), but with no luck.

    First, for anyone trying to reproduce these steps, the only moment I could start strace is after I access the WebEx test meeting page and a security check dialogue appears: if I start it before, it has no PID to attach to and if I start it later, library loading has already passed.

    Second, the grep command doesn’t work for me because I see 2 java processes when I start a WebEx test session:

    $ ps aux | grep java
    me 14247 7.4 0.5 393388 39864 ? Sl 09:37 0:06 /usr/lib/firefox/plugin-container /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/ -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 2726 true plugin
    me 14257 23.7 2.2 4612424 179728 ? Sl 09:37 0:21 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Xbootclasspath/a:/usr/share/icedtea-web/netx.jar:/usr/share/icedtea-web/plugin.jar: -classpath /usr/lib/jvm/java-7-openjdk-amd64/lib/rt.jar sun.applet.PluginMain /run/user/1000/icedteaplugin-me-MYfFu3/14247-icedteanp-plugin-to-appletviewer /run/user/1000/icedteaplugin-me-MYfFu3/14247-icedteanp-appletviewer-to-plugin /run/user/1000/icedteaplugin-me-MYfFu3/14247-icedteanp-plugin-debug-to-appletviewer

    I modified it to the following:

    $ sudo strace -ff -t -p `ps -ef|grep -v grep|grep anp-appletviewer-to-plugin|awk ‘{ print $2 }’ | uniq` -o webex

    When I inspected the output, I saw that the applet was looking for the following libraries in a number of places:, Upon closer inspection, I found that I had every one of them on disk, but not under the locations they were being looked for in.

    I therefore created symlinks under /lib/x86_64-linux-gnu/gtk2 and /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/i386 (for only), but the only result was that WebEx would not start at all, instead of just broken screen sharing.

    Any more (possibly up to date) suggestions?

Leave a Reply

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