Bug 829817 - java-1.7.0-openjdk doesn't work with webex when viewing shared desktops
java-1.7.0-openjdk doesn't work with webex when viewing shared desktops
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: icedtea-web (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Omair Majid
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 11:28 EDT by Peter Robinson
Modified: 2015-02-25 12:23 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-19 14:49:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2012-06-07 11:28:40 EDT
Version: java-1.7.0-openjdk-1.7.0.3-2.1.fc17.7.x86_64

I can connect to a webex session without issue but if another participant shares their desktop I can't see the shared desktop.
Comment 1 Deepak Bhole 2012-06-07 11:52:38 EDT
Is there any way we might be able to reproduce this locally?
Comment 2 Peter Robinson 2012-06-07 12:31:43 EDT
You can get a 14 day free trial here http://www.webex.com/go/us_webex_ft

I've not tried sharing a Linux desktop but you should be able to get a test account and share something. I might be able work with you directly if you can't get some device to share a desktop.
Comment 3 Dmitry Z 2013-03-26 00:21:00 EDT
It's most probably not issue with the openjdk.
I had absolutely the same sympthoms with the Oracle JRE.

See this post on how to trace webex and find out which missing packages are preventing it from running properly

http://www.emsperformance.net/2013/03/25/making-webex-work-on-64bit-fedora-core-18/

In a nut shell - you need to trace your webex java process

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

And then search for open system calls in the webex.???? files

grep open webex.????

And analyze which packages are missing.
In my case (Fedora Core 18 x64) it was missing libpangox-1.0.so.0

And solution to make webex work properly was 

yum install pangox-compat-0.0.2-1.fc18.x86_64
Comment 4 Fedora End Of Life 2013-07-03 21:40:39 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 jiri vanek 2013-08-29 04:11:33 EDT
if insatalling pangox-compat-0.0.2-1.fc18.x86_64 is the solution, shouldnt this be clossed as "have workarround" ?
Yes, we can add pangox to icedtea-web depndences, but its not the desired thing
Comment 6 Peter Robinson 2013-08-29 04:14:35 EDT
(In reply to jiri vanek from comment #5)
> if insatalling pangox-compat-0.0.2-1.fc18.x86_64 is the solution, shouldnt
> this be clossed as "have workarround" ?
> Yes, we can add pangox to icedtea-web depndences, but its not the desired
> thing

Because it's not easily discovered for the average user. Ultimately if java needs that library to operate it should depend on it. End of story
Comment 7 jiri vanek 2013-08-29 05:29:04 EDT
Its not the java who is depending on it. Those are native parts of webex clients who are depending on it.

So the webex native client should statistical linked against pangox or should deliver pangox togehter with it or should  require pangox. From icedtea-web (to add this dependece) would be just friendly step.
Comment 8 Deepak Bhole 2013-09-06 11:42:51 EDT
WebEx should include the library with their archives -- icedtea-web should not pull in anything that a specific application needs.
Comment 9 Thomas Fitzsimmons 2013-09-16 22:04:32 EDT
I spoke to the WebEx developers; the next release of WebEx (T29) will no longer depend on libpangox-1.0.so.0.  I don't know when T29 will be generally available, but definitely not before the end of this month.

In any case, the WebEx team is aware of the issue and have fixed it in their development codebase.
Comment 10 Derek Atkins 2014-07-22 09:38:44 EDT
Unfortunately this is still the case 9 months later.  To get WebEx working on F20-x86_64 today I had to:

yum install icedtea-web gnupg pangox-compat pangox-compat.i686 libXmu.i686 libgcj.i686 java-1.8.0-openjdk.i686

(c.f. http://negativo17.org/enabling-cisco-webex-in-fedora-19-x86_64-and-i686/ )

I'm still getting an error about missing libjawt.so, but the shared screen in webex is now working.
Comment 11 Derek Atkins 2014-07-22 09:52:17 EDT
For the record, here is the backtrace from firefox even after I get it "working":

java.lang.UnsatisfiedLinkError: /home/warlord/.webex/1324/libdbr.so: /home/warlord/.webex/1324/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
	at java.lang.Runtime.loadLibrary0(Runtime.java:849)
	at java.lang.System.loadLibrary(System.java:1088)
	at DBR.loadNativeDBR(DBR.java:22)
	at DBR.loadNativeModule(DBR.java:166)
	at DBR.onDBRMessage(DBR.java:297)
	at DBR.processMessage(DBR.java:319)
	at DB.processMessage(DB.java:431)
	at DB.run(DB.java:397)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
XXX[DBR]load native library failed

And an ldd shows:

ldd /home/warlord/.webex/1324/libdbr.so
	linux-gate.so.1 =>  (0xf77f5000)
	libjawt.so => not found
	libX11.so.6 => /lib/libX11.so.6 (0xf7696000)
	libXmu.so.6 => /lib/libXmu.so.6 (0xf767c000)
	libdl.so.2 => /lib/libdl.so.2 (0xf7677000)
	libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7587000)
	libm.so.6 => /lib/libm.so.6 (0xf7540000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7523000)
	libc.so.6 => /lib/libc.so.6 (0xf7365000)
	libxcb.so.1 => /lib/libxcb.so.1 (0xf7341000)
	libXt.so.6 => /lib/libXt.so.6 (0xf72e3000)
	libXext.so.6 => /lib/libXext.so.6 (0xf72cf000)
	/lib/ld-linux.so.2 (0x484da000)
	libXau.so.6 => /lib/libXau.so.6 (0xf72cb000)
	libSM.so.6 => /lib/libSM.so.6 (0xf72c2000)
	libICE.so.6 => /lib/libICE.so.6 (0xf72a8000)
	libuuid.so.1 => /lib/libuuid.so.1 (0xf72a2000)
Comment 12 Omair Majid 2014-07-22 10:18:13 EDT
(In reply to Derek Atkins from comment #11)
> For the record, here is the backtrace from firefox even after I get it
> "working":

Thanks for the stack trace.

> java.lang.UnsatisfiedLinkError: /home/warlord/.webex/1324/libdbr.so:
> /home/warlord/.webex/1324/libdbr.so: wrong ELF class: ELFCLASS32 (Possible
> cause: architecture word width mismatch)

So this error says that the 32-bit binary (libdbr.so) can not be used. What is your machine architecture? You mentioned Firefox. Is Firefox a 32-bit process?

(In reply to Derek Atkins from comment #10)
> Unfortunately this is still the case 9 months later.  To get WebEx working
> on F20-x86_64 today I had to:
> 
> yum install icedtea-web gnupg pangox-compat pangox-compat.i686 libXmu.i686
> libgcj.i686 java-1.8.0-openjdk.i686

Unfortunately, for an application that's not included in the distribution, it's the application's responsibility to make sure that all its dependencies are available (one way or another). Forcing all icedtea-web users to install pangox-compat and/or libXmu is silly.
Comment 13 Derek Atkins 2014-07-22 10:31:02 EDT
(In reply to Omair Majid from comment #12)
> (In reply to Derek Atkins from comment #11)
> > For the record, here is the backtrace from firefox even after I get it
> > "working":
> 
> Thanks for the stack trace.
> 
> > java.lang.UnsatisfiedLinkError: /home/warlord/.webex/1324/libdbr.so:
> > /home/warlord/.webex/1324/libdbr.so: wrong ELF class: ELFCLASS32 (Possible
> > cause: architecture word width mismatch)
> 
> So this error says that the 32-bit binary (libdbr.so) can not be used. What
> is your machine architecture? You mentioned Firefox. Is Firefox a 32-bit
> process?

Firefox is 64-bit. Java, I don't know -- I have multiple java packages installed.  But I thought that using the plugin-container it could run with 32-bit plugins?  Regardless, it does at least work even tho I'm still getting this stack trace.

> (In reply to Derek Atkins from comment #10)
> > Unfortunately this is still the case 9 months later.  To get WebEx working
> > on F20-x86_64 today I had to:
> > 
> > yum install icedtea-web gnupg pangox-compat pangox-compat.i686 libXmu.i686
> > libgcj.i686 java-1.8.0-openjdk.i686
> 
> Unfortunately, for an application that's not included in the distribution,
> it's the application's responsibility to make sure that all its dependencies
> are available (one way or another). Forcing all icedtea-web users to install
> pangox-compat and/or libXmu is silly.

Well, Webex is a web app.  I didn't actually install anything, it's just a bunch of jar files that get installed when I click on a link in firefox.  So there is no way to have webex actually tell the user that it's missing dependencies because webex doesn't get "installed", it's just loaded.

How about making a meta-package, "webex-web" that just pulls in the dependencies?  At least that way somoene could do a "yum search webex" and find something they could install instead of having to google around to figure out what's wrong.
Comment 14 Omair Majid 2014-07-22 10:47:21 EDT
(In reply to Derek Atkins from comment #13)
> Firefox is 64-bit. Java, I don't know -- I have multiple java packages
> installed.  But I thought that using the plugin-container it could run with
> 32-bit plugins? 

No, A 64-bit Firefox uses a 64-bit plugin. And that would explain the architecture mismatch.

> Regardless, it does at least work even tho I'm still
> getting this stack trace.

That's good.

> > (In reply to Derek Atkins from comment #10)
> Well, Webex is a web app.  I didn't actually install anything, it's just a
> bunch of jar files that get installed when I click on a link in firefox.

Well, webex is doing all kinds of things at this point - installing jars and .so's. Surely it can ask users to install packages appropriate for the user's distribution at this point.

> So
> there is no way to have webex actually tell the user that it's missing
> dependencies because webex doesn't get "installed", it's just loaded.

Well, it gets loaded and then runs without checking if all of its dependencies are available. If nothing else, maybe it can throw an error up to the user and ask him to install it manually?
 
> How about making a meta-package, "webex-web" that just pulls in the
> dependencies? 

Seems to me like this would be against the packaging guidelines:

http://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits

But if you want to create such a package, I wont stop you.
Comment 15 Derek Atkins 2014-07-22 11:26:09 EDT
(In reply to Omair Majid from comment #14)
> (In reply to Derek Atkins from comment #13)
> > Firefox is 64-bit. Java, I don't know -- I have multiple java packages
> > installed.  But I thought that using the plugin-container it could run with
> > 32-bit plugins? 
> 
> No, A 64-bit Firefox uses a 64-bit plugin. And that would explain the
> architecture mismatch.

I'm honestly not sure who is loading what, where..  I really don't want to have multiple firefoxes installed on my system, but if the plugins are only 32 bit I don't know what to do..

> > Regardless, it does at least work even tho I'm still
> > getting this stack trace.
> 
> That's good.

Yeah, after I installed those packages (note, I didn't need to install gnupg -- that got in there by mistake) then it worked.  I'm still getting this stack trace, but the webex itself seems to work, so maybe it tries to load different ways and if one way fails it tries another?

> > > (In reply to Derek Atkins from comment #10)
> > Well, Webex is a web app.  I didn't actually install anything, it's just a
> > bunch of jar files that get installed when I click on a link in firefox.
> 
> Well, webex is doing all kinds of things at this point - installing jars and
> .so's. Surely it can ask users to install packages appropriate for the
> user's distribution at this point.

Maybe..  I'm not a webex developer, just a user.  I wouldn't even know who to ask.  I'm just trying to make it easier for the next guy, I've already solved it for myself and have the notes for next time I install a desktop.

> > So
> > there is no way to have webex actually tell the user that it's missing
> > dependencies because webex doesn't get "installed", it's just loaded.
> 
> Well, it gets loaded and then runs without checking if all of its
> dependencies are available. If nothing else, maybe it can throw an error up
> to the user and ask him to install it manually?

Again, I don't know..  I suspect that it's all behind the covers at that point and might not have a way to notice that things aren't loading properly.

> > How about making a meta-package, "webex-web" that just pulls in the
> > dependencies? 
> 
> Seems to me like this would be against the packaging guidelines:
> 
> http://fedoraproject.org/wiki/Packaging:
> Guidelines#Packages_which_are_not_useful_without_external_bits
> 
> But if you want to create such a package, I wont stop you.

Well, then, it appears we are at a crossroads.  Like I said I solved this for myself; I don't know the right way to move forward on this.  My main goal on commenting here was to enable google to find a workaround when someone finds this bug report, to make it easier for the next guy.
Comment 16 Donald Pellegrino 2015-02-19 14:08:49 EST
(In reply to Derek Atkins from comment #10)
> Unfortunately this is still the case 9 months later.  To get WebEx working
> on F20-x86_64 today I had to:
> 
> yum install icedtea-web gnupg pangox-compat pangox-compat.i686 libXmu.i686
> libgcj.i686 java-1.8.0-openjdk.i686
> 
> (c.f.
> http://negativo17.org/enabling-cisco-webex-in-fedora-19-x86_64-and-i686/ )
> 
> I'm still getting an error about missing libjawt.so, but the shared screen
> in webex is now working.

I am trying to get Cisco WebEx working on F21-x86_64. I am able to join meetings but unable to view or share screens. I tried to install the packages listed in Comment #10, however I receive the following error message:

"No package libgcj.i686 available."

Has libgcj.686 been dropped since F20? Is so, is there an alternative work-around to get WebEx screen sharing working on F21-x86_64?
Comment 17 Omair Majid 2015-02-19 14:46:28 EST
(In reply to Donald Pellegrino from comment #16)
> I am trying to get Cisco WebEx working on F21-x86_64. I am able to join
> meetings but unable to view or share screens. I tried to install the
> packages listed in Comment #10, however I receive the following error
> message:
> 
> "No package libgcj.i686 available."
> 
> Has libgcj.686 been dropped since F20?

Yes. It was dropped from F21 and later.

> Is so, is there an alternative
> work-around to get WebEx screen sharing working on F21-x86_64?

Just a guess, but can you try the same yum command, but leaving out libgcj.i686?
Comment 18 Omair Majid 2015-02-19 14:49:04 EST
Closing as CANTFIX since there's nothing I can do to fix WebEx itself.

Please feel free to reopen if there's something I can do on Fedora-side to fix this.
Comment 19 Donald Pellegrino 2015-02-20 13:37:15 EST
(In reply to Omair Majid from comment #17)
> Just a guess, but can you try the same yum command, but leaving out
> libgcj.i686?

The other packages install successfully. However, the WebEx sessions still do not have the ability to share a screen or to view screens shared by others.
Comment 20 Derek Atkins 2015-02-20 13:46:54 EST
(In reply to Omair Majid from comment #17)
> (In reply to Donald Pellegrino from comment #16)
> > I am trying to get Cisco WebEx working on F21-x86_64. I am able to join
> > meetings but unable to view or share screens. I tried to install the
> > packages listed in Comment #10, however I receive the following error
> > message:
> > 
> > "No package libgcj.i686 available."
> > 
> > Has libgcj.686 been dropped since F20?
> 
> Yes. It was dropped from F21 and later.

Why was libgcj dropped?  It's required to run any package that was compiled with the Gnu Java Compiler (gcj).

> > Is so, is there an alternative
> > work-around to get WebEx screen sharing working on F21-x86_64?
> 
> Just a guess, but can you try the same yum command, but leaving out
> libgcj.i686?

That wont work because the user will still be missing /usr/lib/libgcj.so.14 and other associated libraries.

Donald, what happens if you try to install libgcj from FC20?  Does WebEx work then?
Comment 21 Donald Pellegrino 2015-02-20 15:20:45 EST
Unfortunately, Cisco WebEx sharing still does not work on fc21.x86_64 with libgcj.i686 installed from FC20.

# rpm -ivh --nodeps libgcj-4.8.3-7.fc20.i686.rpm 
warning: libgcj-4.8.3-7.fc20.i686.rpm: Header V3 RSA/SHA256 Signature, key ID 246110c1: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:libgcj-4.8.3-7.fc20              ################################# [100%]

I also checked the dependencies for the WebEx shared libraries in /home/donaldpellegrino/.webex/1524

[donaldpellegrino@localhost 1524]$ ldd *.so | grep -i "not"
	libjawt.so => not found
	libjawt.so => not found

Note that libjawt.so is on the system, just not being found by ldd:

[donaldpellegrino@localhost 1524]$ locate libjawt.so
/usr/lib/gcj-4.8.3/libjawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.i386/jre/lib/i386/libjawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.x86_64/jre/lib/amd64/libjawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.x86_64/lib/amd64/libjawt.so

I could add one of these to LD_LIBRARY_PATH and clear the shared library dependency problem but I presume the JRE takes care of that on its own.

I captured the output from firefox while connecting to a WebEx meeting. It looks like it is running the 64-bit JRE. The JRE is failing when trying to load native 32-bit libraries for WebEx. Similar behavior was observed as per comment 11 from a "working" installation so it is unclear what consequence this ELF mismatch has.

[donaldpellegrino@localhost Downloads]$ firefox
openjdk version "1.8.0_31"
OpenJDK Runtime Environment (build 1.8.0_31-b13)
OpenJDK 64-Bit Server VM (build 25.31-b07, mixed mode)
Codebase matches codebase manifest attribute, and  application is signed. Continuing. See: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/no_redeploy.html for details.
JDownload version 2014.07.21
Java version: 1.8.0_31
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.x86_64/jre
OS name: Linux
OS arch: amd64
OS version: 3.18.7-200.fc21.x86_64
[JDownload] Java Client Service home:https://dow.webex.com/client/T29LSP12/javaclient/webex/
[JDownload] Production home: /home/donaldpellegrino/.webex/1524
[MySystem version 2014.12.11.01]InitSystem ... 
Begin of log initialization
initFileOutputStream() run ...
4
End of log initialization
###1 Runtime total memory: 74448896, free memory: 57925520
###2 Runtime total memory: 92798976, free memory: 83388720
###### try to load class DBR in MyCloassLoader2...
Loading native DBR...
OpenJDK 64-Bit Server VM warning: You have loaded library /home/donaldpellegrino/.webex/1524/libdbr.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libdbr.so: /home/donaldpellegrino/.webex/1524/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at DBR.loadNativeDBR(Unknown Source)
	at DBR.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at dB.c(Unknown Source)
	at MySystem.InitSystem(Unknown Source)
	at JDownload.run(JDownload.java:297)
	at java.lang.Thread.run(Thread.java:745)
XXX[DBR]load native library failed
###1 Runtime total memory: 92798976, free memory: 82823992
###2 Runtime total memory: 92274688, free memory: 82929360
###### try to load class DBR in MyCloassLoader2...
Loading native DBR...
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libdbr.so: /home/donaldpellegrino/.webex/1524/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at DBR.loadNativeDBR(Unknown Source)
	at DBR.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at dB.c(Unknown Source)
	at MySystem.InitSystem(Unknown Source)
	at JDownload.run(JDownload.java:297)
	at java.lang.Thread.run(Thread.java:745)
XXX[DBR]load native library failed
###1 Runtime total memory: 92274688, free memory: 82430560
###2 Runtime total memory: 96468992, free memory: 87129560
###### try to load class DBR in MyCloassLoader2...
Loading native DBR...
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libdbr.so: /home/donaldpellegrino/.webex/1524/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at DBR.loadNativeDBR(Unknown Source)
	at DBR.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at dB.c(Unknown Source)
	at MySystem.InitSystem(Unknown Source)
	at JDownload.run(JDownload.java:297)
	at java.lang.Thread.run(Thread.java:745)
XXX[DBR]load native library failed
Time ParamPDChain ===> 1
Resource: svc
Resource: svc_en
Resource: svc_en_US
###### try to load class JNRW in MyCloassLoader2...
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libatdv.so: /home/donaldpellegrino/.webex/1524/libatdv.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at JNRW.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at sD.a(Unknown Source)
	at kF.<init>(Unknown Source)
	at jmeetingclient.q(Unknown Source)
	at di.b(Unknown Source)
	at jmeetingclient.init(Unknown Source)
	at JDownload.run(JDownload.java:322)
	at java.lang.Thread.run(Thread.java:745)
XXX[JNRW]load native library failed
###1 Runtime total memory: 96468992, free memory: 38601344
###2 Runtime total memory: 100139008, free memory: 85153464
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libatdv.so: /home/donaldpellegrino/.webex/1524/libatdv.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at JNRW.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at sD.a(Unknown Source)
	at kF.<init>(Unknown Source)
	at jmeetingclient.q(Unknown Source)
	at di.b(Unknown Source)
	at jmeetingclient.init(Unknown Source)
	at JDownload.run(JDownload.java:322)
	at java.lang.Thread.run(Thread.java:745)
XXX[JNRW]load native library failed
###1 Runtime total memory: 100139008, free memory: 85059376
###2 Runtime total memory: 100663296, free memory: 88479080
java.lang.UnsatisfiedLinkError: /home/donaldpellegrino/.webex/1524/libatdv.so: /home/donaldpellegrino/.webex/1524/libatdv.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1835)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1119)
	at JNRW.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
	at java.lang.Class.newInstance(Class.java:438)
	at sD.a(Unknown Source)
	at kF.<init>(Unknown Source)
	at jmeetingclient.q(Unknown Source)
	at di.b(Unknown Source)
	at jmeetingclient.init(Unknown Source)
	at JDownload.run(JDownload.java:322)
	at java.lang.Thread.run(Thread.java:745)
XXX[JNRW]load native library failed
chat component version = 2013.08.15.29.00003
Resource: atlchat
Resource: atlchat_en
Resource: atlchat_en_US
notes component version = 2010.04.27.0001
Resource: atnotes
Resource: atnotes_en
Resource: atnotes_en_US
Resource: atpoll2
Resource: atpoll2_en
Resource: atpoll2_en_US
Polling Component 06/22/2011
Resource: commonres
Resource: commonres_en
Resource: commonres_en_US
Resource: atutil
Resource: atutil_en
Resource: atutil_en_US
clearAllMenus...
[JDownload] applet destroy
### [MySystem]cleanup ... 
DBR.cleanup, m_this=DBR@523650a4,inited=false
###1 Runtime total memory: 100663296, free memory: 64084224
###2 Runtime total memory: 129499136, free memory: 112859760
[donaldpellegrino@localhost Downloads]$
Comment 22 Omair Majid 2015-02-20 15:32:55 EST
(In reply to Donald Pellegrino from comment #21)
> [donaldpellegrino@localhost 1524]$ ldd *.so | grep -i "not"
> 	libjawt.so => not found
> 	libjawt.so => not found
> 
> Note that libjawt.so is on the system, just not being found by ldd:
>
> I could add one of these to LD_LIBRARY_PATH and clear the shared library
> dependency problem but I presume the JRE takes care of that on its own.

Yup. The JRE will load up the right libjawt.so (some JRE versions ship with more than one libjawt.so) when it starts.
 
> I captured the output from firefox while connecting to a WebEx meeting. It
> looks like it is running the 64-bit JRE. The JRE is failing when trying to
> load native 32-bit libraries for WebEx. Similar behavior was observed as per
> comment 11 from a "working" installation so it is unclear what consequence
> this ELF mismatch has.

A x86_64 process can not use i686 libraries. If you want to run the i686 WebEx, you will have to use a i686 Firefox and an i686 JDK. Otherwise, any non-Java code that WebEx uses (like for screen sharing?) will not work.
Comment 23 Derek Atkins 2015-02-20 15:46:22 EST
(In reply to Omair Majid from comment #22)
> (In reply to Donald Pellegrino from comment #21)
> > [donaldpellegrino@localhost 1524]$ ldd *.so | grep -i "not"
> > 	libjawt.so => not found
> > 	libjawt.so => not found

For what it's worth I still have this particular "issue" on FC20, but WebEx works for me..

> > I captured the output from firefox while connecting to a WebEx meeting. It
> > looks like it is running the 64-bit JRE. The JRE is failing when trying to
> > load native 32-bit libraries for WebEx. Similar behavior was observed as per
> > comment 11 from a "working" installation so it is unclear what consequence
> > this ELF mismatch has.
> 
> A x86_64 process can not use i686 libraries. If you want to run the i686
> WebEx, you will have to use a i686 Firefox and an i686 JDK. Otherwise, any
> non-Java code that WebEx uses (like for screen sharing?) will not work.

Sorry, Omair, but this is just not true.  I'm running 64-bit firefox on FC20 but WebEx works just fine for me!  I can share my screen and see shared screens.  So the ELF 32 v 64 bit is a Red Herring.
Comment 24 Omair Majid 2015-02-20 15:49:14 EST
(In reply to Derek Atkins from comment #23)
> Sorry, Omair, but this is just not true.  I'm running 64-bit firefox on FC20
> but WebEx works just fine for me!  I can share my screen and see shared
> screens.  So the ELF 32 v 64 bit is a Red Herring.

Hmm.. Are you using a 32 bit JRE by any chance?
Comment 25 Derek Atkins 2015-02-20 15:58:19 EST
(In reply to Omair Majid from comment #24)
> (In reply to Derek Atkins from comment #23)
> > Sorry, Omair, but this is just not true.  I'm running 64-bit firefox on FC20
> > but WebEx works just fine for me!  I can share my screen and see shared
> > screens.  So the ELF 32 v 64 bit is a Red Herring.
> 
> Hmm.. Are you using a 32 bit JRE by any chance?

Possibly.  I have multiple installed:

rpm -qa | grep ^java-
java-1.7.0-openjdk-javadoc-1.7.0.71-2.5.3.0.fc20.noarch
java-1.7.0-openjdk-devel-1.7.0.71-2.5.3.0.fc20.x86_64
java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64
java-1.8.0-openjdk-1.8.0.0-0.19.b106.fc20.i686
java-1.7.0-openjdk-headless-1.7.0.71-2.5.3.0.fc20.x86_64

I don't know which one runs behind firefox.
Comment 26 Donald Pellegrino 2015-02-25 12:23:01 EST
An alternative to running the 32-bit Cisco WebEx plugin with 64-bit Firefox and 64-bit JRE might be to run a 32-bit browser. The browser would then load a 32-bit JRE and the WebEx plugin. I installed google-chrome-stable.i386 as distributed by Google to try this approach.

$ yum info google-chrome-stable
Loaded plugins: langpacks
Installed Packages
Name        : google-chrome-stable
Arch        : i386
Version     : 40.0.2214.115
Release     : 1
Size        : 179 M
Repo        : installed
From repo   : google-chrome
Summary     : Google Chrome
URL         : http://chrome.google.com/
License     : Multiple, see http://chrome.google.com/
Description : The web browser from Google
            : 
            : Google Chrome is a browser that combines a minimal design with sophisticated technology to make the web faster,
            : safer, and easier.

Unfortunately, it seg faults when I attempt to run it.

$ google-chrome
Segmentation fault (core dumped)

Perhaps this indicates a bigger problem with running 32-bit binaries on fc21.x86_64?

Note You need to log in before you can comment on or make changes to this bug.