32-bit plugins in 64-bit opera
Friday, 26. October 2007, 09:22:38
I see repeatedly comments that people run 32-bit plugins in 64-bit Opera by using the nspluginwrapper. This wrapper "enables you to use plugins on platforms they were not built for".
However in Opera, as opposed to other browsers, there is no need to go through the hassel of installing an extra plugin wrapper to do that - the operapluginwrapper handles it just fine!
The only issue is that you need to be using the 32-bit operapluginwrapper in a 64-bit Opera to run 32-bit plugins. Currently the only way to do so is to download a 32-bit Opera (I'd reccomend downloading a tarball), extract it, and replace the installed (64-bit) wrapper with the operapluginwrapper from the 32-bit package - and voilà, all 32-bit plugins should work out-of-the-box.
Currently this is manual work (sorry for that), but we are looking into having this handled at installation time - and have a way of seamlessly dealing with both 32-bit and 64-bit plugins (since you'll need the 64-bit wrapper for the 64-bit plugins…).
However in Opera, as opposed to other browsers, there is no need to go through the hassel of installing an extra plugin wrapper to do that - the operapluginwrapper handles it just fine!
The only issue is that you need to be using the 32-bit operapluginwrapper in a 64-bit Opera to run 32-bit plugins. Currently the only way to do so is to download a 32-bit Opera (I'd reccomend downloading a tarball), extract it, and replace the installed (64-bit) wrapper with the operapluginwrapper from the 32-bit package - and voilà, all 32-bit plugins should work out-of-the-box.
Currently this is manual work (sorry for that), but we are looking into having this handled at installation time - and have a way of seamlessly dealing with both 32-bit and 64-bit plugins (since you'll need the 64-bit wrapper for the 64-bit plugins…).
You must be logged in to write a comment. if you're not a registered member, please 
By Zajec, # 26. October 2007, 14:45:20
As far as how much data must be downloaded in order to do that, it's less data to download if they only have to grab Opera64 with 32 and 64 wrappers in it, compared to downloading both Opera64 and Opera32.
By IceArdor, # 26. October 2007, 17:00:34
By csant, # 26. October 2007, 21:15:50
That's excellent news! +1
I did what you said, but I got this error:
By Cyro, # 27. October 2007, 13:09:20
If I copy the 32bit version of "operapluginwrapper" from a tarball over my 64bit installation got the exactly same error from above.
I'm not able to install Adobe Flash 9 on Opera 9.50 AMD64 version. The only way to do that, is to use the i386 version of kestrel.
By Cyro, # 26. December 2007, 20:28:41
I had a similar problem on freebsd with the linux version of operapluginwrapper. I think the problem is caused by the linker finding the 64bit version of some X11 libs instead of the 32bit versions. You can try to create a replacement operapluginwrapper script that sets up correct library search path for 32bit and exec's the original wrapper.
disclaimer: I solved my problem in different manner, but I think this approach should work, too.
cheers,
mitch
By mitch0, # 31. December 2007, 00:15:14
"32-bit plugins (like Flash) and 64-bit plugins now work out-of-the-box in 64-bit Linux builds."
I got this error message while trying to use it:
Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
opera: Plug-in 12140 is not responding. It will be closed.
opera: Define environment variable OPERA_KEEP_BLOCKED_PLUGIN to keep blocked plug-ins.
Note: Ubuntu 7.10 Gutsy Gibbon AMD64 using "opera_9.50-20080103.2-shared-qt_amd64.deb" and latest release of Adobe 9 (stable)
root@ubuntu:/usr/lib/mozilla/plugins# ls -la
-rwxrwxrwx 1 root root 8119784 2008-01-04 16:18 libflashplayer.so
root@ubuntu:/usr/lib/mozilla/plugins# ldd libflashplayer.so
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib32/libdl.so.2 (0xf76fb000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf76e3000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf75f1000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf75e3000)
libXt.so.6 => /usr/lib32/libXt.so.6 (0xf7592000)
libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7522000)
libfontconfig.so.1 => /usr/lib32/libfontconfig.so.1 (0xf74f7000)
libgtk-x11-2.0.so.0 => /usr/lib32/libgtk-x11-2.0.so.0 (0xf7172000)
libgobject-2.0.so.0 => /usr/lib32/libgobject-2.0.so.0 (0xf7136000)
libglib-2.0.so.0 => /usr/lib32/libglib-2.0.so.0 (0xf7079000)
libm.so.6 => /lib32/libm.so.6 (0xf7054000)
libc.so.6 => /lib32/libc.so.6 (0xf6f0a000)
/lib/ld-linux.so.2 (0x56555000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf6f07000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf6f02000)
libSM.so.6 => /usr/lib32/libSM.so.6 (0xf6ef9000)
libICE.so.6 => /usr/lib32/libICE.so.6 (0xf6ee1000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf6ecc000)
libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf6eac000)
libgdk_pixbuf-2.0.so.0 => /usr/lib32/libgdk_pixbuf-2.0.so.0 (0xf6e94000)
libgdk-x11-2.0.so.0 => /usr/lib32/libgdk-x11-2.0.so.0 (0xf6e0c000)
libpangocairo-1.0.so.0 => /usr/lib32/libpangocairo-1.0.so.0 (0xf6e03000)
libpango-1.0.so.0 => /usr/lib32/libpango-1.0.so.0 (0xf6dc6000)
libXcomposite.so.1 => /usr/lib32/libXcomposite.so.1 (0xf6dc3000)
libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf6dc0000)
libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf6dbb000)
libatk-1.0.so.0 => /usr/lib32/libatk-1.0.so.0 (0xf6d9f000)
libgmodule-2.0.so.0 => /usr/lib32/libgmodule-2.0.so.0 (0xf6d9b000)
libcairo.so.2 => /usr/lib32/libcairo.so.2 (0xf6d24000)
libXrender.so.1 => /usr/lib32/libXrender.so.1 (0xf6d1c000)
libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf6d19000)
libXi.so.6 => /usr/lib32/libXi.so.6 (0xf6d10000)
libXrandr.so.2 => /usr/lib32/libXrandr.so.2 (0xf6d0a000)
libXcursor.so.1 => /usr/lib32/libXcursor.so.1 (0xf6d01000)
libpangoft2-1.0.so.0 => /usr/lib32/libpangoft2-1.0.so.0 (0xf6cd3000)
libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf6cb0000)
By Cyro, # 4. January 2008, 16:29:58
By cbinusa, # 7. March 2008, 15:50:54