51376 - 4.x plugins don't work with HP-UX N6 builds

Status: RESOLVED DUPLICATE of bug 106806

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

Description

[John Gaunt (redfive)]

Linux N6 build runs the 4.x version of the adobe acrobat plugin, HPUX N6 build 
does not.

Comment 1

[John Gaunt (redfive)]

av, pls re-assign to me, I guess the automated system put you in by default.

thanks,
jgaunt

Comment 2

[av (gone)]

We need to clarify here. 
1. Summary says about plugins in general. Did you try Flash, e.g.?
2. Acrobat can serve as a plugin or a helper app. It is known that as aplugin it 
doesn't work on any Unix platform (Shirang, is this correct?). But it works as a
helper at least on Linux.

Reassigning, and cc'ing myself.

Comment 3

[shrirang khanzode]

Yes,Andrei, till 0901 build, I was unable to launch acrobat as a plugin. I will 
try this with a fresh build and see if it makes any difference.

Comment 4

[John Gaunt (redfive)]

I have run Adobe's Acrobat, a plugin called SwiftView and the libtextplugin that 
is in the tree. The only one I have been able to get working on HP is the 
textplugin. I was unable to get the textplugin to work on Linux actually. One of 
our QA guys got the acrobat working in Linux, although I'm not sure if as a 
plugin or as a helper-app ( ccing jimmyu ).

For HP, the problem lies in the loading of libraries. Seamonkey is not linked 
against the same set of libraries Nova(4.x) is linked against. Therefore when 
the plugins look for certain symbols they aren't there. The solution in 
nsPluginsDirUnix.cpp put in for Linux that loads the libraries at runtime 
doesn't work for HP. I'm in contact with some HP people to find out if there is 
a way we can figure out a similar solution for HP.

Comment 5

[Jim Dunn]

making child of toplevel hp bug

Comment 6

[John Gaunt (redfive)]

accepting

Comment 7

[Brian Nesse (gone)]

See my comments in bug 57885 (2001-01-18 14:45) regarding plug-in file names. 
This might be your problem.

Comment 8

[Barrett Lindstrom]

Adding myself on the CC list.

Comment 9

[karnaze (gone)]

Marking m1.0. 

Comment 10

[John Gaunt (redfive)]

This has to do with motif vs. gtk differences. 4.x plugins have been dropped for
linux N6 and I don't see us changing that for HP alone. Marking won't fix.

Comment 11

[Barrett Lindstrom]

Verifying old bugs.

Comment 12

[Jim Dunn]

reopening... 

Comment 13

[Jim Dunn]

updating

Comment 14

[Jim Dunn]

What I found is that for 4.x plugins to work we need to make
sure libXm is loaded.  The current logic, tries to load a
plugin, if it fails to load, THEN and ONLY THEN do we try
to load several X libs (including libXm) before retrying to
load the plugin.  The thought being that the plugin won't
load without unresolved symbols, so if it doesn't load, maybe
it is because libXm (and other X libs) aren't loaded, so
load them which will resolve the symbols.

The problem with HP is that the plugin GETS loaded even though
it has unresolved symbols, so we never TRY to load libXm.  What
we need to do (on HP) is to FORCE the loading of libXm either
by linking it (at build time) or at runtime (PR_LoadLibrary(libXm).

Comment 15

[Jim Dunn]

Attachment: patch to link plugin module against -lXm for legacy plugin support

My linking against -lXm, legacy plugins that linked against this
in the past can now load.  I was able to load Acrobat Reader & Real
plugins.  Additionally on AIX, this same patch allows me to 
load Acrobat Reader.

Comment 16

[Dan Dickerman]

It seems that this is a workaround in Mozilla to fix a broken assumption in
the plugins: the plugins assume that libXm is already available in the 
browser (and in the casese where the browser is built with gtk it is not), 
but the plugins do not themselves enforce the needed dependency.  That said, 
it does seem a bit late to go back to Adobe, etc, and tell them that they 
can't assume Motif is already linked-in and to please re-link their plugins
so that they force a dependency on libXm.sl.

An alternative on HP-UX is to wrap these plugins into a filter library which 
references both the original plugin and the libraries that they assume to be
available.  For example:

ld -b -o mypdf.so +filter /usr/lib/libXm.sl  \
   +filter /opt/Acrobat4/Browsers/hppahpux/nppdf.so

Creates a filter library which is a front-end to these other two.  Putting 
mypdf.so in the plugins directory will pull-in these other two when it is
loaded.

A more general alternative seems to be just copying the needed libraries
themselves into the plugins directory -- In the above example: cp
/usr/lib/libXm.sl /opt/plugins/libXm.so seems to make it as available as needed
for plugins to use.  Don't know how much of that is an HP-specific workaround,
but both of the above seem to work.

Comment 17

[Jim Dunn]

Attachment: on HP-UX, link against -lXm

The only HP plugin that needs this is Adobe Acrobat Reader.  They
have unresolved symbols (XmProcessTraversal) if we don't link -lXm
into the plugin shared library.

Comment 18

[Jim Dunn]

Adding cls & serge

Ok this isn't very nice (ifdef HP) but it works.
Would you like me to instead add extra thing to autoconf.mk
EXTRA_PLUGINS_LIBS or something that on HP-UX I set to -lXm
and then have a line like

EXTRA_DSO_LDOPTS += $(EXTRA_PLUGINS_LIBS)

I can do that but it will take a bit of time and hit several files.
let me know

Comment 19

[hacker formerly known as [e-mail]]

jdunn: I think that you attached the wrong patch. 

Wrt the loading of the plugin not failing and the extra libs not loading, is
that when using the pref listed from bug 105334?  Using EXTRA_PLUGINS_LIBS
sounds like a good idea to me.

Comment 20

[Jim Dunn]

Attachment: doh, new patch, link -lXm for HP

adding correct patch, however, I will look at switching
this to EXTRA_PLUGIN_LIBS

Comment 21

[Jim Dunn]

as it turns out, we don't need the -lXm, we just need to look at both
.sl & .so for extensions, which was fixed in bug 106806

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