> Ok, something *just* hit me, and I checked: sure enough, that link was
> under amd64, and this new box is running Xeons. Now, the other admin says
> they're as compatible as any i386 instruction set.
>
> And locate tells me the only libnpjp2.so is under amd64....
>
> So, I'm stumped.
I have previously found that the 32-bit version of the new java plugin does
not work under 64-bit - it crashes just like you described. Maybe it broke
at a particular revision, maybe it never worked. The old 32-bit plugin did
generally work on 64-bit.
When nspluginwrapper is present, the firefox wrapper script will always
use wrapped plugins *instead* of native plugins, which in the case of
java will go horribly wrong. This is a bug IMHO - the firefox wrapper
should always put the native plugins first and then the wrapped ones.
/usr/bin/firefox:
...
## Select the propper plugin dir
## Wrapped plug-ins are located in /lib/mozilla/plugins-wrapped
##
if [ -x "/usr/bin/mozilla-plugin-config" ]
then
MOZ_PLUGIN_DIR="plugins-wrapped"
else
MOZ_PLUGIN_DIR="plugins"
fi
...
if [ "$MOZ_PLUGIN_PATH" ]
then
MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR
else
MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/$MOZ_PLUGIN_DIR:$MOZ_DIST_BIN/$MOZ_PLUGIN_DIR
fi
...
But wait, here's more: the firefox wrapper calls /usr/bin/mozilla-plugin-config,
if installed. This script, in turn, runs $LIBDIR/nspluginwrapper/plugin-config,
which is *suid*. So, every user running firefox messes around in system dirs.
Who came up with that bright idea?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
