Backward adapter allowing to run older(4x) plugins in new browser explicitly linked with libXt and libxtgtk - it's bad as loading of Sun's Java VM requires that some symbols to be used from Motif, not libXt. Really from nsglsrc/nsPluginsDirUNIX.cpp ______________________________________________________________ nsresult nsPluginFile::LoadPlugin(PRLibrary* &outLibrary) { PRLibSpec libSpec; PRLibSpec tempSpec; PRLibrary * handle; /////////////////////////////////////////////////////////// // Normally, Mozilla isn't linked against libXt and libXext // since it's a Gtk/Gdk application. On the other hand, // legacy plug-ins expect the libXt and libXext symbols // to already exist in the global name space. This plug-in // wrapper is linked against libXt and libXext, but since // we never call on any of these libraries, plug-ins still // fail to resolve Xt symbols when trying to do a dlopen // at runtime. Explicitly opening Xt/Xext into the global // namespace before attempting to load the plug-in seems to // work fine. __________________________________________________________________ I.e. it's loaded explicitly anyway. So it's possible simply remove libXt and libxtgtk dependencies from plugin Makefile. It's blocker for running Sun's JVM in browser address space and required to be fixed ASAP.

On 24 October 13:02:07, Nikolay Igotti wrote: > > Problem: > > If libXt is loaded before libXm, it defines dummy > vendorShellWidgetClass > and vendorShellClassRec, and if after it > you'll load Motif dependent library > (for example in AWT on Unix) as > dynamical linker is lazy, it will use > vendorShellWidgetClass and > vendorShellClassRec from libXt. But this structure > is not completly > inited to be used by Motif. So your program SIGSEGV. > > Solution. > > I(nikolay.igotti@eng.sun.com) wrote small DLL doing following thing: > - it predefines vendorShellWidgetClass and vendorShellClassRec, so > linker always refers to them if wishes to resolve those symbols. > - it overrides dlopen() in such a manner, that until you've got > desired value it dlsym() every loaded library to see if it defines > vendorShellClassRec and memcpy() structure if needed. See sources for > exact logic. > It works on both Linux and Solaris(dynamical/stacal Motif) and allows > to run Motif-based AWT in process (so pluglets and Java DOM can > work). Also it should allow running of all Motif based Netscape > plugins. I know it's hackish solution, but we have no choise.

Is this problem specific to Mozilla only, or does it affect the branded Netscape 6 client (based on Mozilla) as well?

It affects both, as Gecko plugin library depends on libXt to provide old style plugins expected environment. Although my fix is JDK specific, it can be made rather generic (for all Motif-based plugins).

IIUC, this bug is a blocker for Java support in N6 RTM on Linux. Nominating rtm to put on radar. Andrei's swamped. Could someone at Sun take this on?

Good news: according to Geroge, turns out this is *not* a blocker for Java support on Linux in N6 RTM. We can support Java as-is in RTM without fixing this. Fixing this bug is necessary as an architectural enhancement going forward to enable a solution with higher performance. Removing rtm nomination.

Yes, it doesn't affect Java Plugin as it runs in another process on Mozilla. So RTM removed correctly, and really it mainly important for Blackwood project, as it requires in-process Java VM. Provided attachments fixes the problem on Linux and Solaris, and can be used by developers of other Motif based in-process plugins.

Per request by YiMing, reassign this bug to YiMing Chung!

Marking m0.9. Can you meet this milestone? Otherwise please change it.

Since some plugins need libXt to be loaded before libXm while some (such as JAVA VM) need libXm to be loaded before libXt, this bug cannot be resolved as long as this discrepancy exits. Mark this bug as invalid.

Lots of verifications. If I had to test stuff, it was on Win2K, build id 2001052404.