12:21 p.m.
The IcedTea java plugin for firefox does not seem to load on F8. I manually
added the link in /usr/lib/mozilla/plugins but to no avail. I notice the
plugin directory is amd64. I am on an Intel chip. Could this be a problem?
Mark Bidewell
12:24 p.m.
Mark Bidewell writes:
The IcedTea java plugin for firefox does not seem to load on F8. I
manually added the link in /usr/lib/mozilla/plugins but to no
avail. I notice the plugin directory is amd64. I am on an Intel
chip. Could this be a problem?
No, but the 64 / 32 bit difference could be. Are you using a 32-bit
IcedTea ? A 32-bit Mozilla ? A 32-bit OS ?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
12:41 p.m.
Mark Bidewell wrote:
The IcedTea java plugin for firefox does not seem to load on F8.
Confirmed.
$ rpm -q firefox java-1.7.0-icedtea-plugin
firefox-2.0.0.8-2.fc8.x86_64
java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8.x86_64
symlinking
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so
to
/usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
did the trick tho.
-- Rex
12:49 p.m.
On 10/31/07, Rex Dieter <rdieter(a)math.unl.edu> wrote:
symlinking
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so
to
/usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
did the trick tho.
Was the symlink going to an outdated location or was it just missing?
-jef
12:57 p.m.
I think the issue is that the link is in the wrong location or the firefox
search path is incorrect. the link was created in
/usr/lib64/mozilla/plugins not /usr/lib/firefox-2.0.0.8/plugins. Oddly
however totem seems to load and that is in /usr/lib64/mozilla/plugins.
On 10/31/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 10/31/07, Rex Dieter <rdieter(a)math.unl.edu> wrote:
> symlinking
> /usr/lib/jvm/java-
1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/gcjwebplugin.so
> to
> /usr/lib64/firefox-2.0.0.8/plugins/gcjwebplugins.so
> did the trick tho.
Was the symlink going to an outdated location or was it just missing?
-jef
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
1:05 p.m.
On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu> wrote:
I think the issue is that the link is in the wrong location or the
firefox
search path is incorrect. the link was created in
/usr/lib64/mozilla/plugins
yeah that sounds like a firefox issue.
looking at /usr/bin/firefox script on my F7 install.
sorry for the line breakage on the script logic.
the relevant script logic seems to be,
if [ "$MOZ_PLUGIN_PATH" ]
then
MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:
$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
else
MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
fi
export MOZ_PLUGIN_PATH
where MOZ_LIB_DIR is ealier defined as:
MOZ_ARCH=$(uname -m)
case $MOZ_ARCH in
x86_64 | ia64 | s390 )
MOZ_LIB_DIR="/usr/lib64"
SECONDARY_LIB_DIR="/usr/lib"
;;
* )
MOZ_LIB_DIR="/usr/lib"
SECONDARY_LIB_DIR="/usr/lib64"
;;
esac
Is this directory calculation logic screwing up?
-jef
1:18 p.m.
I wind up with a MOZ_PLUGIN_PATH path of:
/usr/lib64/mozilla/plugins-wrapped:/usr/lib64/firefox-
2.0.0.8/plugins-wrapped
/usr/lib64/firefox-2.0.0.8/plugins-wrapped doesn't exist so
/usr/lib64/firefox-2.0.0.8/plugins must be hardcoded.
The F8 logic is:
##
## Make sure that we set the plugin path
##
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
export MOZ_PLUGIN_PATH
MOZ_LIB_DIR being defined as in F7.
Mark Bidewell
On 10/31/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu> wrote:
> I think the issue is that the link is in the wrong location or the
firefox
> search path is incorrect. the link was created in
> /usr/lib64/mozilla/plugins
yeah that sounds like a firefox issue.
looking at /usr/bin/firefox script on my F7 install.
sorry for the line breakage on the script logic.
the relevant script logic seems to be,
if [ "$MOZ_PLUGIN_PATH" ]
then
MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:
$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
else
MOZ_PLUGIN_PATH=$MOZ_LIB_DIR/mozilla/plugins:$MOZ_DIST_BIN/plugins
fi
export MOZ_PLUGIN_PATH
where MOZ_LIB_DIR is ealier defined as:
MOZ_ARCH=$(uname -m)
case $MOZ_ARCH in
x86_64 | ia64 | s390 )
MOZ_LIB_DIR="/usr/lib64"
SECONDARY_LIB_DIR="/usr/lib"
;;
* )
MOZ_LIB_DIR="/usr/lib"
SECONDARY_LIB_DIR="/usr/lib64"
;;
esac
Is this directory calculation logic screwing up?
-jef
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
1:24 p.m.
On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu> wrote:
MOZ_LIB_DIR being defined as in F7.
So its the new
$MOZ_PLUGIN_DIR definition that is causing the problem here.
Is -wrapped something 64bit specific? Or is plugins-wrapped always
going to be available on all arches? I wonder if there are any other
plugin packages which actually get burned by the change in plugin
path.
-jef
1:47 p.m.
I'm just guessing but it would seem logical that plugins-wrapped contains 32
to 64 bit wrappers.
On 10/31/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu> wrote:
> MOZ_LIB_DIR being defined as in F7.
So its the new $MOZ_PLUGIN_DIR definition that is causing the problem
here.
Is -wrapped something 64bit specific? Or is plugins-wrapped always
going to be available on all arches? I wonder if there are any other
plugin packages which actually get burned by the change in plugin
path.
-jef
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
2:54 p.m.
Jeff Spaleta (jspaleta(a)gmail.com) said:
On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu>
wrote:
> MOZ_LIB_DIR being defined as in F7.
So its the new $MOZ_PLUGIN_DIR definition that is causing the problem here.
Is -wrapped something 64bit specific? Or is plugins-wrapped always
going to be available on all arches? I wonder if there are any other
plugin packages which actually get burned by the change in plugin
path.
plugins-wrapped is searched if nspluginwrapper is installed. I suspect
running 'mozilla-plugin-config -i -f' (as root) would fix the original
issue.
Bill
4:31 p.m.
That did seem to correct the problem
On 10/31/07, Bill Nottingham <notting(a)redhat.com> wrote:
Jeff Spaleta (jspaleta(a)gmail.com) said:
> On 10/31/07, Mark Bidewell <mark.bidewell(a)alumni.clemson.edu> wrote:
> > MOZ_LIB_DIR being defined as in F7.
> So its the new $MOZ_PLUGIN_DIR definition that is causing the problem
here.
>
> Is -wrapped something 64bit specific? Or is plugins-wrapped always
> going to be available on all arches? I wonder if there are any other
> plugin packages which actually get burned by the change in plugin
> path.
plugins-wrapped is searched if nspluginwrapper is installed. I suspect
running 'mozilla-plugin-config -i -f' (as root) would fix the original
issue.
Bill
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
6:09 p.m.
> > MOZ_LIB_DIR being defined as in F7.
> So its the new $MOZ_PLUGIN_DIR definition that is causing the problem here.
>
> Is -wrapped something 64bit specific? Or is plugins-wrapped always
> going to be available on all arches? I wonder if there are any other
> plugin packages which actually get burned by the change in plugin
> path.
plugins-wrapped is searched if nspluginwrapper is installed. I suspect
running 'mozilla-plugin-config -i -f' (as root) would fix the original
issue.
I was having problems with the java (and swfdec-mozilla too) not
working on x86_64 (yes all 64 bit packages).
For the java if I went to about:plugins it was listed. If I went to
www.java.com it and selected the detect option it detected version
1.7.0 so that looked OK, but a couple of java sites I use on occasion
would come back with errors saying java wasn't installed.
For swfdec (yes I know its not part of Fedora) it wouldn't even detect
it in about:plugins.
I tried the above and got the following:
[root@euuklonw7300b1n ~]# mozilla-plugin-config -i -f
*** NSPlugin Viewer *** ERROR: libxpcom.so: cannot open shared object
file: No such file or directory
[root@euuklonw7300b1n ~]# ldconfig -v | grep libxp
[root@euuklonw7300b1n ~]#
A rpm gave me
[root@euuklonw7300b1n ~]# rpm -ql firefox| grep libxpcom
/usr/lib64/firefox-2.0.0.8/components/libxpcom_compat_c.so
/usr/lib64/firefox-2.0.0.8/libxpcom.so
/usr/lib64/firefox-2.0.0.8/libxpcom_compat.so
/usr/lib64/firefox-2.0.0.8/libxpcom_core.so
[root@euuklonw7300b1n ~]#
So I added a /etc/ld.so.conf.d/firefox.conf file with
/usr/lib64/firefox-2.0.0.8/ in it. Ran a ldconfig and restarted
firefox and it all started working.
So I'm not sure if there's suppose to be links for libxpcom.so or
something else or whether the plugins have issues. Let me know if you
want more details.
Peter
6021
days inactive
6021
days old
11 comments
6 participants
participants (6)
-
Andrew Haley -
Bill Nottingham -
Jef Spaleta -
Mark Bidewell -
Peter Robinson -
Rex Dieter