65055 - ns4 plugins (and Java) won't load if XFree86-devel libs are not installed

Status: VERIFIED DUPLICATE of bug 69167

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Frederic Crozat]

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

Comment 1

[Frederic Crozat]

Attachment: Patch to load non-development libraries

Comment 2

[Asa Dotzler [:asa]]

setting bug status to New

Comment 3

[Ronald van Kuijk]

duplicate of #5118­9?

Comment 4

[Frederic Crozat]

I would not say duplicate since #5118­9 only talks about Java (not flash plugin)
but it kind of related.. And this bug provides a real fix, not a LD_PRELOAD thing..

Comment 5

[serge (gone)]

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.

Comment 6

[Frederic Crozat]

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

[karnaze (gone)]

George, does relate to the work you discussed in the plugin meeting at Netscape 
2 weeks ago?

Comment 8

[drapeau]

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.

Comment 9

[Frederic Crozat]

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..)

Comment 10

[serge (gone)]

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

[karnaze (gone)]

Moving to m0.9. serge, can you meet this milestone?

Comment 12

[av (gone)]

Is bug 51189 a dup of this one?

Comment 13

[drapeau]

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.

Comment 14

[Frederic Crozat]

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

Comment 15

[serge (gone)]

Moving to m0.9.1

Comment 16

[karnaze (gone)]

*** Bug 71163 has been marked as a duplicate of this bug. ***

Comment 17

[Marek Z. Jeziorek]

Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.

Comment 18

[Jussi-Pekka Mantere]

Bumping to 0.9.3.

Comment 19

[Stephan Jaensch]

*** Bug 69167 has been marked as a duplicate of this bug. ***

Comment 20

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 21

[av (gone)]

*** This bug has been marked as a duplicate of 69167 ***

Comment 22

[shrirang khanzode]

verf dup