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.
Is there any way we might be able to reproduce this locally?
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.
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
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.
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
(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
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.
WebEx should include the library with their archives -- icedtea-web should not pull in anything that a specific application needs.
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.
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.
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)
(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.
(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.
(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.
(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.
(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?
(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?
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.
(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.
(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?
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]$
(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.
(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.
(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?
(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.
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?