Test Env: Mozilla 1.1.b on hpux11, acrobat's read 4.05 repeat steps: 1. download package download url = http://www.adobe.com/products/acrobat/alternate.html filename=hpux-rs-405.tar.gz 2. install run steps gunzip -c hpux-rs-405.tar.gz | tar xvf - cd HPUXRS.install ./INSTALL (will install to path /opt/Acrobat4) 3. config steps PATH=/opt/Acrobat4/bin:$PATH export PATH make softlink ln - s /opt/Acrobat4/Browsers/hppahpux/nppdf.so /home/tst/mozilla/dist/bin/plugins/np pdf.so 4. err result when load a pdf file, mozilla crash and the result are $ ./mozilla md5sum not found. Warning: Actions not found: addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown Warning: Actions not found: ManagerGadgetNextTabGroup, ManagerGadgetPrevTabGroup, DrawingAreaInput, addBookmark, viewBookmark, copy, undefined-key, find, findAgain, history, loadImages, openURL, mailNew, new, openFile, print, exit, reload, saveAs, paste, delete, cut, undo, historyItem, back, forward, abort, PageUp, PageDown /usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code) from /opt/Acrobat4/Browsers/hppahpux/nppdf.so BTW, Mozilla 1.1b(win) is fine. rgds, Jonathan.

>/usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code) because motif libXm cannot be found, which is strange. Can launch stand alone acrobat?

hmmm my guess is that the acrobat plugin requires mozilla to be linked against -lXm I had a bug against this, but didn't feel it was necessary. Fix is simple in modules/plugin/base/src/Makefile.in for HP-UX link with -lXm

Fixed and steps: 1) I can launch /opt/Acrobat4/bin/acroread stand alone, then open a pdf file successfully. (2) I can also let netscape 4.7 on hpux works with above steps for viewing pdf. Fixed. (3) vi /mozilla/modules/plugin/base/src/Makefile, add CXXFLAGS +=-lXm touch * ; gmake clean; gmake; (4) relaunch, now it works. Thanks,

up, you don't mark it fixed until code has been checked into the trunk that fixes the problem. re-opening and assigning to martin btw you should use cxxflags for adding -lXm you should use EXTRA_DSO_LDOPTS

reassigning

Reference: Bug 51376

Comment on attachment 96742 [details] [diff] [review] Patch updated for OEM branch I would add the same 3 lines for MOZ_ENABLE_XLIB r=serge

Reassigning QA Contact. Moving shrir@netscape.com to CC list.

So... is this patch in need of checking in? Has it been checked in? What's the state of things here?

No it isn't fixed. HOWEVER, if this is going to get fixed it should be fixed similar to bug 98892. NOTE: I haven't tested this patch, I am not sure of the $target_os case since all other cases involved just $target. Will verify tomorrow (note this is needed on both 11 & 10.20).

marking NEW

1. Bug 188941 seems to be a duplicate of this one 2. I also see this on Sparc Solaris

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

Now confirming this on Sparc Solaris with both the 4.x and 5.x plugins. Additional note: This worked some month ago -> regression? Didn't update for a while in between because of another (now fixed) bug...

no, not a regression. Chances are the solaris builds you were getting were either based on the OEM branch or had this patch included in them. But the fix has never hit the trunk. Patch needs to be updated to include solaris, reviewed and checked in. NOTE: also removing *fixed* from summary. *fixed* only applies to the 1.0 OEM branch, which is indicated via keyward fixedOEM.

The -- snip -- /usr/lib/dld.sl: Unresolved symbol: XmProcessTraversal (code) -- snip -- indicats that the plugin code assumes the main application is linked against the Motif libs (Motif-1 unformtunately in the NS4.x case... ;-( ). So a question to the Solaris users who see this bug: Does it help to start Mozilla like this: % (LD_PRELOAD=/usr/dt/lib/libXm.so.3 ./mozilla) # ?

Bingo! Starting with LD_PRELOAD as described in comment #19 fixes the problem on Solaris. Is there a way to fix that in the builds or will I have to use that var setting from now on?

Jens Hatlak wrote: > Bingo! Starting with LD_PRELOAD as described in comment #19 fixes the problem > on Solaris. Is there a way to fix that in the builds or will I have to use > that var setting from now on? It may be better to contact the _plugin_vendor_ to fix their plugin code (and maybe someone tells them that /usr/dt/lib/libXm.so.3 is the old&&buggy Motif1 lib and that Motif2 (e.g. /usr/dt/lib/libXm.so.4) should be used instead), it seems it is simply missing a linker reference to /usr/dt/lib/libXm.so.3 Implementing that hack for Mozilla is _NOT_ recommended since it will likely break plugins which use newer Motif libraries (like the Motif2 lib in /usr/dt/lib/libXm.so.4). One possible option would be to write a small piece of code which checks whether 1. any libXm.* is not being refernced (see output of /usr/bin/ldd) by the plugin shared library (*.so) and 2. check whether there are any symbols in the code which starts with "Xm" (case-sensitive) If both [1] and [2] are "true" then /usr/dt/lib/libXm.so.3 should be loaded if the plugin instantiation has failed previously (e.g. first we would try to load and instantiate the plugin without the hack, and if that fails then test [1] and [2] - and if both conditions are "true" then try the hack...).

IMHO asking the plugin vendor to fix this is silly. (do you want me to go into why it is silly...) THE CORRECT FIX IS TO GET THE CORRECT PATCH CHECKED IN! This should have been taken care of a year ago but wasn't. IBM/AIX got there fix/patch in and HP-UX/Solaris should follow suit. Someone just has to own this and do it!

Can people test this and let me know?!?

This bug is open now for quite some time and this is a pity because it worked for a long time before this became (in my eyes) a regression. However, I think it's partly my fault because I reported the Solaris problem and then didn't answer after the patch was posted here. The reason was that I'm not that familiar with building Mozilla and had to wait until someone with enough knowledge from our university could apply the patch, build and let me test. That finally happened and here is the *result*: 1. There's no more crash (on Sparc Solaris; either Acrobat 4 or 5) 2. The Acrobat 5 plugin does nothing at all; Mozilla just stops loading. 3. The Acrobat 4 plugin outputs the following: "Acrobat plug-in. Could not find Acrobat External Window Handler Plugin." and nothing else happens. The only other plugin installed is Java 1.4.2, I'm using a fresh profile and a Forte-compiled Sparc Solaris build of Mozilla 1.5a with nothing modified but the patch attached to this bug being applied, Calendar enabled and XPrint disabled. While I don't know if this affects Acrobat/this bug, I should also note that I'm unable to (let) Mozilla compile with gcc, let it be 2.9x or 3.x (for reasons not to be discussed here). HTH

Jens Hatlak pointed me in the direction of this bug. I think he saw the checkin in HEAD for my patch in bug 211587 which has been verified to solve the crash for Solaris. I think this is slighly different from bug 98892, where AIX needs special linking order to not crash for several plugins. This is simply about the Acrobat plugin not beeing linked with libXm as it should. The unix plugin code already has some tricks to handle this (quite similar to what Roland suggested in comment 21). I'll attach a patch shortly which is a bit more general version of my Solaris patch with updated comment and add libXm to HPUX.

Patch against the branches, HEAD looks slightly different. Someone with a HPUX should test this! I can only speak for the Solaris case. Will attach patch against HEAD as soon as I recieve some response on this one.

This subsumes the Solaris patch from 211587 by adding HPUX to libXm-list, moving the LoadLibrary with PR_LD_NOW within the GTK-defines and adds an else for non-gtk-builds so that they remain unaffected. Tested on linux and solaris.

Comment on attachment 132134 [details] [diff] [review] nsPluginsDirUnix.cpp patch against trunk. Peter, could you please take a look at this one? It is almost the same you gave r in bug 211587, except adapted for HP-UX as well. Seems no one with HP-UX actually cared enough to try it, but it should work as the same work-arounds as for Solaris worked...

I will try the patch on HP-UX build with Acrobat and update the bug.

Tested the patch on HP-UX and it works fine.

Comment on attachment 132134 [details] [diff] [review] nsPluginsDirUnix.cpp patch against trunk. Seeking sr and checkin for this patch. Has r from peterlubczynski. Tested on Linux, Solaris and HPUX (thanks Kishan!).

Comment on attachment 132134 [details] [diff] [review] nsPluginsDirUnix.cpp patch against trunk. sr=bzbarsky

Patch checked in.

This has been fixed in Mozilla for some time now. Just to close the issue raised by me in comment 24: I managed to get Acrobat 5 work by setting execution permissions on both the plugin itself (nppdf.so) and the *.api files (chmod o+x). I don't know if they are set by default and were only unset here at university by our maintainers but it's clear that this can be fixed with the steps outlined above. Enjoy!

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