Closed
Bug 65055
Opened 24 years ago
Closed 23 years ago
ns4 plugins (and Java) won't load if XFree86-devel libs are not installed
Categories
(Core Graveyard :: Plug-ins, defect, P3)
Tracking
(Not tracked)
mozilla0.9.4
People
(Reporter: fred, Assigned: srgchrpv)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
BuildID: 2001011016 When loading Java plugin (from JRE 1.3.0_01) or old ns4 plugins (flash for exampke), Mozilla tries to load libXt.so directly, which is not installed by default on desktop computers (only on developpement stations). Reproducible: Always Steps to Reproduce: Install Java plugin (symlinking libjavaplugin_oji.so) Be sure you don't have libXt.so installed (only libXt.so.6) Start Mozilla Actual Results: => Java plugin is not loaded Expected Results: Java Plugin should be loaded There is two possible workaround : -either LD_PRELOAD both libXm.so.2 and libXt.so.6 (in that order) -correct library loading in unix plugin loader (ugly patch attached
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 4•24 years ago
|
||
I would not say duplicate since #51189 only talks about Java (not flash plugin) but it kind of related.. And this bug provides a real fix, not a LD_PRELOAD thing..
Assignee | ||
Comment 5•24 years ago
|
||
I've posted the patch to fix http://bugzilla.mozilla.org/show_bug.cgi?id=69167 I think is a dup of this one or vice versa. About Frederic's patch: we do link against libXt.so.6 explicitly in libgtkxtbin.so, but some legacy plugins could be linked against libXt.so as well, so if we do not have that lib dlopen() call fails and returns null... The patch I mentioned above will try to print out to sdterr some err message if dlopen() fails.
Reporter | ||
Comment 6•24 years ago
|
||
I don't think your patch for bug #69167 is a dup of my patch : on a standard Linux system (ie not installed to do developement stuff), there is no libXt.so (it is only used to compile Xt stuff).. Your patch only says there is a problem when loading a plugin, but a newbie won't be able to correct the problem. With my patch, problem never occurs..
Comment 7•24 years ago
|
||
George, does relate to the work you discussed in the plugin meeting at Netscape 2 weeks ago?
Yep, it sounds like the same kinda thing I was talking about. Look at bug 51189 for details. Our current thinking is different than the patch for this bug; I can't see a valid reason why libXt and libXext should be manually loaded into the process space at all. Our suggestion is to remove those lines in nsPluginFile::LoadPlugin() altogether. By the way, the current attachment to this bug, a potential way to fix the problem, won't necessarily work. It's a bad idea to include the version number explicitly in the name of the shared library being opened. On Solaris 8, for example, the version of libXt distributed is libXt.so.4, not .so.6. This patch would break Mozilla on Solaris 8 and earlier, at least. I'm curious about the comment earlier in this bug that libgtkxtbin.so links against libXt. Can somebody put a comment in here explaining what that library is, what it does, and why it needs to link against libXt? It seems weird to me that a GTK app needs any symbols from the Xt library. Besides, if old-style plugins are Motif binaries (or some other Xt-based widget set), those plugins will have their own link-time dependencies and I can't see why they need the browser to pre-load any X libraries. Anybody who can explain the above will go a long way toward clearing out this bug and 51189, and making the Mozilla code a little cleaner, and also reduce the run-time memory footprint by a few hundred KBytes, in my opinion.
Reporter | ||
Comment 9•24 years ago
|
||
I know this patch should not load libXt.so.6 (that is why I call it ugly :)) And of course, the best solution would be to use system dynamic loader to load libXt by itself (and not by dlopen..)
Assignee | ||
Comment 10•24 years ago
|
||
I think the best way to find out about libgtkxtbin.so is its sources and authors: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtkxtbin/gtkxtbin .c&rev=&root=/cvsroot#21 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/gtkxtbin/Makefile .in&rev=&root=/cvsroot#36
Comment 11•24 years ago
|
||
Moving to m0.9. serge, can you meet this milestone?
Assignee: av → serge
Target Milestone: --- → mozilla0.9
Comment 13•24 years ago
|
||
There's another workaround: add something to the Mozilla installer that puts a symlink from somewhere in $MOZILLA to point to libXt.so.6. For example: ln -s $MOZILLA/dist/bin/components/libXt.so /usr/X11R6/lib/libXt.so.6 Ideally, you'd also put in a check that you actually *have* a libXt.so.6. On Solaris the simple-minded symlink wouldn't work because there's no libXt.so.6 distributed, only a libXt.so.4. Ultimately, it's bad code to do a dlopen() on a specific version of a shared object library. The dynamic linker should find the right version for you, or the operating system should come with the proper symlink. But failing that, I think the make-the-symlink-at-install time workaround is the best answer here. That's my opinion, anyway.
Reporter | ||
Comment 14•24 years ago
|
||
Why not detect which libXt.so.major is installed at configure time (using configure.in) and either : - define a LIBXT_MAJOR in configure and use it in code - create symlink with correct major number (detected by configure) as proposed by drapeau at install time
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 17•24 years ago
|
||
Setting target milestone to 0.9.2 (check it in anytime, even before, when the tree is open for). Per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Priority: -- → P3
Keywords: mozilla0.9.3
Comment 20•24 years ago
|
||
Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 21•23 years ago
|
||
*** This bug has been marked as a duplicate of 69167 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•