Closed Bug 189461 Opened 22 years ago Closed 22 years ago

Linux, Solaris: RealPlayer and Java plugin can't access libxpcom symbols

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: frederik.reiss, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

Attachments

(2 files)

Hack to workaround the plugin loading misbehavior
2.09 KB, text/plain
Details
xpcom/glue/standalone/nsXPCOMGlue.cpp patch based on comment 68
1.14 KB, patch
peterlubczynski-bugs
: review+
dougt
: superreview+
dbaron
: approval1.3b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117

since today mozilla does not detect the java plugin (2003011705). All other
plugins that i have installed work.

Reproducible: Always

Steps to Reproduce:
1.goto about:plugins
2.see, there is no java plugins listed


Actual Results:  
Java does not work. (it is not shown in about:plugins)

Expected Results:  
mozilla should find the java plugin and use it when it's needed.

I use j2re1.4.1_01
I'm seeing this too.  It worked yesterday.
Severity: major → blocker
I'm getting these errors, which are new:

LoadPlugin: failed to initialize shared library /opt/IBMJava2-131/jre/bin/libjav
aplugin_oji.so [/opt/IBMJava2-131/jre/bin/libjavaplugin_oji.so: undefined symbol
: assign_from_helper__13nsCOMPtr_baseRC15nsCOMPtr_helperRC4nsID]

LoadPlugin: failed to initialize shared library /home/blizzard/RealPlayer8/rpnp.
so [/home/blizzard/RealPlayer8/rpnp.so: undefined symbol: __pure_virtual]
Status: UNCONFIRMED → NEW
Ever confirmed: true
I should start mozilla from the console bevore i report a bug :(

o.k. here is the error message that i get:

LoadPlugin: failed to initialize shared library
/opt/j2re1.4.1_01/plugin/i386/ns600/libjavaplugin_oji.so
[/opt/j2re1.4.1_01/plugin/i386/ns600/libjavaplugin_oji.so: undefined symbol:
GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]

But the realplayer8 plugin has no error message on my mozilla.

->oji
Assignee: peterlubczynski → joshua.xia
Component: Plug-ins → OJI
QA Contact: shrir → petersen
The error in comment 3 is the standard error one gets when using a build
compiled with gcc3 with the Java plugin.  The errors in comment 2 look new.
This happens on the nightly & my own builds, and my own builds are build using
gcc 2.95.4.
why is this a blocker?
because java funcationality is part of the smoketests.  no java, no smoketest.
This is a blocker because loading a java applet is a smoketest and this just broke.
dougt: i think you get this fun bug :)
Assignee: joshua.xia → dougt
Component: OJI → XPCOM
QA Contact: petersen → scc
this works on mac and windows. it's linux only.
linux only in summary
Summary: Mozilla does not detect the java plugin → Linux-only: Mozilla does not detect the java plugin
IBM string in the errors, adding mkaply
It looks to me like a shared library used by the plugins changed such that they
can't load it any more.

The IBM thing is a red herring because someone is using the IBM JvM.

The Java plugin actually links directory to XPCOM and other shared objects. Did
some entry point get removed that Java linked against?
I just verified that the OS/2 Java plugin IS loading. This is interesting
because source code wise, it was based on the same code as the Linux plugin.

Is there any utility on Linux to query a shared object for what other shared
objects it is dependent on and whether or not it can load them?
The AIX IBM Java plugin 1.3.1 also works properly with today's build.
comment 2 (Real8) sounds very similar to bug 187437 for which culprit was bug 74786.
using build 20030117 on Linux, I get the same warning as comment 3 with Sun's
JRE 1.4.1_01 but no console warning if I use Blackdown's JRE 1.4.1 and applets
work as usual.
I am downgrading.  I don't own their code - nor have seen it.  There is nothing
I can do to prevent the java plugin from breaking since it uses symbols which
are not frozen.
Severity: blocker → critical
This looks like the error message I get on a GTK2 build on 1.3a.

LoadPlugin: failed to initialize shared library /home/blizzard/RealPlayer8/rpnp.
so [/home/blizzard/RealPlayer8/rpnp.so: undefined symbol: __pure_virtual]

I have seen other bugs in bugzilla on the above.

(RealPlayer 9 has other problems (notice that it has its own libXm.so.2)!

To do a GCC3 Java build that works on my GCC3 built mozilla build see:

http://www.linuxfromscratch.org/~tushar/

regards,
Do other plugins still work?  flash, etc.?
Linux build 2003011708: Flash 6.0r69 works, JRE 1.4.1 (Blackdown) works,
mplayerplug-in 0.23 works. Listed correctly in about:plugins.

see also bug 116444 comment 85 for Sun's JRE and GCC 3.x where Pete Zha from Sun
says 1.4.2 will fix this. Perhaps we can get them to fix this bug too.
adding pete zha
*** Bug 189594 has been marked as a duplicate of this bug. ***
I am not sure this bug is due to an unfrozen interface changing.  nm tells me
that libxpcom.so is still exporting
GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager.  It seems
rather that the Jave plugin is not able to dynamically link to libxpcom.so at
all.  (Maybe related to the GRE changes?)

I can get the error to go away and Java to work if I preload libxpcom.so (export
LD_PRELOAD=libxpcom.so).
*** Bug 189687 has been marked as a duplicate of this bug. ***
I have 2 boxes running Sun's j2re-1.4.0_01-fcs.  One works and one does not. 
The working box has Moz build mozilla-1.2b-2002111716_trunk_rh7 as built by
Aleksey Nogin.  The non-working us running mozilla-1.3b-2003011416_trunk_rh8. 
The RH8 box did work until about a month ago.  I just assumed that I munged
something until no matter what I did I could not get it to work.  My error
messages are of this variety.........

LoadPlugin: failed to initialize shared library
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so
[/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so: undefined
symbol: GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]

This reflects an upgrade to 1.4.1 that I hoped would fix the problem.  I saw the
same message under 1.4.0.
Linux only? I try 2003/01/09 source on solaris, this bug doesn't happen.
i am not sure where this bug should go.  to default owner of OJI
Assignee: dougt → joshua.xia
Component: XPCOM → OJI
QA Contact: scc → petersen
I see this on 20031020-trunk gcc 2.95 build mozilla JRE1.4.1_01.
As comment 25 said, it works if I set LD_PRELOAD=libxpcom.so
So, I think it's not a compiler version problem. Any library expert could
explain why? Seems xpcom has not been loaded when mozilla load plugin...
Component: OJI → XPCOM
Sorry for changing components
back to OJI
Component: XPCOM → OJI
I tested today 's trunk on Solaris, java work well.
Unless the bug is fixed before 1.3b, I would suggest describing the LD_PRELOAD
workaround described in comment 25 in the Release Notes (makes the problem go
away also for me - build 2003012022, JRE1.4.0_01, RedHat 7.3)
cc:ing dougt re: comment #30, did something change w.r.t loading xpcom?

Can we just always set LD_PRELOAD=libxpcom.so before starting moz?
I've just modified the startup script as proposed in comment 25 and it works.
(Redhat 7.3)
It would be nice if that were done at source until the real problem is fixed
otherwise installing new builds will be a pain.

Alternatively add a file called AWARNING with instructions to insert

   export LD_PRELOAD=libxpcom.so

in the mozilla start up script..
Thanks.
no, setting LD_PRELOAD=libxpcom.so will work only until the GRE is moved unto a
new directory.  


The core of the problem is that the java plugin links to xpcom.  That should be
fix and this problem will go away. (not like I haven't said that before *ducks*)
Are you planning on moving the GRE to another directory?  I really hope that
Mozilla is not planning to ship 1.3 with Java support for Linux.
Damn. I meant "without", of course.
*** Bug 190036 has been marked as a duplicate of this bug. ***
I don't think this is a duplicate of 190036.  When I go to Help/About plugins
I get
Java(TM) Plug-in 1.4.0-b92
    File name: libjavaplugin_oji140.so
    Java(TM) Plug-in1.4.0
followed by a long list.  Yet when I try to load a page that requires Java,
I get the alert asking if I want to download the plug-in.  (I did that, again,
and it didn't help.)
I'm using build 2003012110 for Linux.  (It has other bugs that prevent
me from copying examples of links.)

*** Bug 190276 has been marked as a duplicate of this bug. ***
According to Blizzard 's comment #2.

IBM/Sun Java Plugin and RealPlayer8 Plugin need libxpcom.so to be loaded first
and then the plugins can be loaded.

So the problem should be the order of loading.
Seeing the comment #3 's messages on the console, but java-plugin appears in
about:plugins, as it used to do.

checked with nightly 2003012408 on RH7.3 and Sun's JDK1.4.1_01
It seems that this bug has been fixed, unless something changed when
I re-installed redhat 8. (My hard drive broke tuesday night. It was replaced
under guarantee in wednesday. I reinstalled RH 8, and eventually put back
all the pieces.

Finally I got the latest nightly build of mozilla1.3b 20030125 and installed
it and found that it now just works with java without my having to edit
the startup file as in comment 25.
E.g. it works just fine with this Java robot
demo:http://www.robotics.stanford.edu/users/nilsson/trweb/TRTower/TRTower_JAVASCRIPT.html

So is it now fixed?
Aaron

Not fixed for me, anyhow.  Jave does not work in 2003-01-25-05 trunk without the
hack from comment 25.
The bug may show up depending on which libraries are loaded by other applications.
My layman's understanding.

Probably unlikely.  This bug appeared suddenly with one of teh nightly builds,
and disappeared just as quickly when I reverted to 2003011508,
Interesting.
I saw the bug in later nightlies and I had never seen it before.
I didn't try earlier builds to see when it appeared.
I assumed that it was a fluke that it never showed up before.

I think i just figured this out... 

I was seeing the same problem and i remembered that the only thing i upgraded
was my binutils recently. I had

% ld -v
GNU ld version 2.13.2

I just pulled from ftp.gnu.org/gnu/binutils/binutils-2.13.2.1.tar.bz2
rebuilt it and now have

% ld -v   
GNU ld version 2.13.2.1

I recompiled mozilla from todays cvs build which *earlier today* failed with

LoadPlugin: failed to initialize shared library
/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so
[/usr/java/j2re1.4.1_01/plugin/i386/ns610/libjavaplugin_oji.so: undefined
symbol: GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]

and now it works just fine !!! No more java errors and i haven't changed
anything  else !!! So it must be a bad 'ld' (or other binutil) from the
2.13.2 package not doing the right thing. 


Someone else please confirm and then resolve this bug. Thanx.




> ld -v

Not sure if you really found the problem. I haven't changed ld for a while on my
system. It's still
  GNU ld version 2.11.93.0.2 20020207
from RedHat 7.3, and it wasn't updated recently.

False alarm by me  - sorry. This behavior has resurfaced even with
the newer ld. Dang !
version 2003012422 works with Java 1.3.1  (Pre-installed with SUSE 8.0)

Seeing bug with trunk version 2003012422, and Java 1.4.1 (Downloaded from Java site)

For me, I can't get the "export LD_PRELOAD=libxpcom.so" to work.
1. Have to provide full path to libxpcom.so.
2. Once that lib is loaded, compains about an xpcom depndancy as follows:
/bin/sh: error while loading shared libraries: libplds4.so: cannot open shared
object file: No such file or directory.
Update the following preload works:
export LD_PRELOAD="$LD_PRELOAD $dist_bin/libxpcom.so"export
LD_PRELOAD="/usr/local/mozilla/libxpcom.so /usr/local/mozilla/libplds4.so
/usr/local/mozilla/libplc4.so /usr/local/mozilla/libnspr4.so"

As LD_PRELOAD behaviour is obviously inconsistent between configuations,
I hope the developers concentrate on a proper fix in Mozilla/Java.
This is wider than just Linux.

I'm using Solaris nightly build 2003012223. Mozilla works fine until it needs
the java plugin, then Mozilla crashes with ld.so.1:
/usr/local/mozilla/mozilla-bin: fatal: relocation error: file
/usr/local/j2sdk1.4.1/jre/plugin/sparc/ns600/libjavaplugin_oji.so: symbol
GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager: referenced
symbol not found
Killed

Using Sun's Java 1.4.1 on SPARC/Solaris 8
I'm confused by all of the traffic on this.  My question is: does anyone know
what changed after 2003011508 (the build to which I have reverted) to break this?
LD_PRELOADing libxpcom.so, libplds4.so, libplc4.so and libnspr4.so works 
also on Solaris. Having this work without that workaround would be nice
though.

option 1: add LD_PRELOAD in boot script.
option 2: coding to force to load libxpcom.so before load plugins

which is better?
Option [2], please... :-)

... it may be usefull to wrap the matching code (|dlopen()| ?!) with a prefs
check ("plugins.force_libxpcom_load_before_plugin_instantiation" (better name
wanted :)) that we are able to turn the code "on"/off" on demand (default should
be "on" for now).
what i want to know is *why in the world* are we managing to load plugins
*before* xpcom.  But right now i have better things to do than to play with GRE
since it only causes problems.

If someone is interested in providing stack traces showing when the loadplugin
call happens and when xpcom is loaded, i'd appreciate them.  -- I might even do
something based on that.
what timeless said.  this is not happening.

also - i do not think either options as a viable workaround to this bug.  
# export LD_PRELOAD="/usr/local/mozilla/libxpcom.so
/usr/local/mozilla/libplds4.so /usr/local/mozilla/libplc4.so
/usr/local/mozilla/libnspr4.so"

Is a sucessful workaround for me.
Mozilla 1.3b
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030129

Why did this bug surface in one of the nightlies and it wasn't present before?

How can I set LD_PRELOAD without using the full path to Mozilla libraries?
It seems my system doesn't look in /usr/local/mozilla for libraries.

Actually this works just fine (assuming your mozilla dir
is /usr/local/mozilla and you are using ksh/bash)

LD_LIBRARY_PATH=/usr/local/mozilla LD_PRELOAD=libxpcom.so /usr/local/mozilla/mozilla
I've added a hack for this to solve the problem outside fixing the
mozilla source. Read the caveats therein.
Hope you like the hack !
If I use the LD_PRELOAD suggestion, then the java plugin works, but I get an
error with the acroread helper app:

ld.so.1: /home/.share/addon/acrobat_5.0/Reader/sparcsolaris/bin/acroread: fatal:
relocation error: file /home/tell
abd-3/edatools/utilities/mozilla/mozilla_2003-01-28/libxpcom.so: symbol main:
referenced symbol not found


Solaris8   Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030128
FWIW, the Acrobat 4.0.5 plugin works fine here (Solaris 8/x86). 

Here's how I startup mozilla (Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.3b)
Gecko/20030119):

BASE=/soft/mozilla-1.3b
cd $BASE
LD_LIBRARY_PATH=${BASE}:${LD_LIBRARY_PATH} \
LD_PRELOAD="${BASE}/libxpcom.so ${BASE}/libplds4.so ${BASE}/libplc4.so
${BASE}/libnspr4.so" \
./mozilla "\$@"


To install the Java plugin, I did:
 ln -sf /soft/JDK-1.4.1/jre/plugin/i386/ns610/libjavaplugin_oji.so
$BASE/$PKG/plugins


To install the Acrobat/PDF plugin, I did:
 ln -sf /soft/acroread-4.0.5/Browsers/intelsolaris/nppdf.so $BASE/$PKG/plugins

For kicks, I'm looking into the Flash plugin at
http://www.tools.de/solaris/flash/ right now. ;)


  - Hubert

*** Bug 191288 has been marked as a duplicate of this bug. ***
Keywords: smoketest
Flags: blocking1.3b?
I've been troubleshooting this on solaris. It looks as though libxpcom.so is
being dynamically loaded without the RTLD_GLOBAL flag, so its symbols aren't
searched by default during relocation processing. The java plugin doesn't
contain an explicit dependency on libxpcom.so so it has presumably been
dependent on libxpcom's symbols being mode RTLD_GLOBAL.

I checked a version of mozilla from early december; the mozilla-bin binary
contains a dependency on libxpcom.so, which would have caused libxpcom.so to be
loaded by the dynamic linker with RTLD_GLOBAL. The current mozilla-bin doesn't
contain this dependency. Instead, libxpcom.so is being loaded through an
explicit call to dlopen() by way of PR_LoadLibrary(), which doesn't set the
RTLD_GLOBAL flag.

Here's part of a truss of mozilla-bin showing it load libxpcom.so. I've included
calls to the dynamic linker lib in the truss:

20766/1:        open("/home/kherron/.gre.config", O_RDONLY)     Err#2 ENOENT
20766/1:        open("/etc/gre.conf", O_RDONLY)                 Err#2 ENOENT
20766/1:        -> ld:dlopen(0x9a050, 0x1, 0xff3a12e8, 0xff3e66b4)
20766/1:        open("/opt/mozilla/libxpcom.so", O_RDONLY)      = 3
20766/1:        mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFEBB0000
20766/1:        mmap(0x00000000, 1400832, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3,
0) = 0xFEA00000
20766/1:        mmap(0xFEB34000, 107824, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED, 3, 1196032) = 0xFEB34000
20766/1:        mmap(0xFEB50000, 18820, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFEB50000
20766/1:        close(3)                                        = 0
20766/1:        <- ld:dlopen() = 0xfebe0c3c

You can see the second arg to ld:dlopen() is 0x1, RTLD_LAZY. RTLD_GLOBAL isn't
set. This is the first appearance of libxpcom.so in the trace.

I gather this trace corresponds to GRE_Startup() and XPCOMGlueStartup() in
xpcom/glue/standalone/nsXPCOMGlue.cpp. In calls PR_LoadLibrary() to load
libxpcom; this eventually calls dlopen() with a flags value of just RTLD_LAZY.

Assuming this is correct, the quick fix would be to change XPCOMGlueStartup() to
use PR_LoadLibraryWithFlags(..., PR_LD_LAZY|PR_LD_GLOBAL). Unfortunately I'm not
in position to test this right now.
Summary: Linux-only: Mozilla does not detect the java plugin → Linux, Solaris: Java plugin can't access libxpcom symbols
I've tested this on linux and solaris. Java works without trouble.

There are other ways to resolve this, of course. PR_LoadLibrary() could be
changed to load libraries with the PR_LD_GLOBAL flag, or libxpcom.so could be
restored to the dependency list for mozilla-bin.
*** Bug 191513 has been marked as a duplicate of this bug. ***
I think dougt would probably prefer for the shim to live in plugins.

nsPluginFile::LoadPlugin already has one shim (Xt/Xext) so it would appear to be
the correct place for additional shims.

All things considered, I think that I like attachment 113086 [details]'s approach. In
fact, I wonder if we could use that approach to replace the shims we currently
have in LoadPlugin.
Assignee: joshua.xia → peterlubczynski
Component: OJI → Plug-ins
QA Contact: petersen → shrir
Summary: Linux, Solaris: Java plugin can't access libxpcom symbols → Linux, Solaris: RealPlayer and Java plugin can't access libxpcom symbols
For Debian people trying to find a solution for non-loading java plugin, I
suggest installing old libstdc libraries.

For example my Debian unstable installation uses newer libraries and the java
plugin can't load properly since it requires a specific library
(libstdc++-libc6.1-1.so.2) which is not found in my install.

This results in a similiar problem which people commenting on this thread are
facing; the java plugin never shows up in about:plugins.

The same problem exists also with all opera browsers so this is definately a
java (& Debian?) problem.

With Debian systems install package libstdc++2.9-glibc2.1 to fix the problem.

Hope this helps somebody - if anyone knows other threads this post might help
more, please, by all means forward it there :)
That is not the solution here. I run debian, have said library installed (on
woody) and experience this. This is a solution to a different problem dealing
with the C library the java plugin is linked against.
*** Bug 191727 has been marked as a duplicate of this bug. ***
*** Bug 191725 has been marked as a duplicate of this bug. ***
FYI: System SuSE 8.1, kernel 2.4.19-4GB-SuSE and 2.4.20. Problem is to reproduce
with both. Error message:

LoadPlugin: failed to initialize shared library
/usr/java/j2re1.4.1_01/plugin/i386/ns600/libjavaplugin_oji.so
[/usr/java/j2re1.4.1_01/plugin/i386/ns600/libjavaplugin_oji.so: undefined
symbol: GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]


I also use RealPlayer 8.0, and it runs perfectly.
*** Bug 191766 has been marked as a duplicate of this bug. ***
Comment on attachment 113203 [details] [diff] [review]
xpcom/glue/standalone/nsXPCOMGlue.cpp patch based on comment 68

r=dougt.  Looks good.
Attachment #113203 - Flags: superreview+
Comment on attachment 113203 [details] [diff] [review]
xpcom/glue/standalone/nsXPCOMGlue.cpp patch based on comment 68

Nice patch Ken!
r=peterl

Requesting drivers approval for moz1.3b: This patch is needed to get Java 1.4
working again on Unix.
Attachment #113203 - Flags: review+
Attachment #113203 - Flags: approval1.3b?
Attachment #113203 - Flags: approval1.3b? → approval1.3b+
Does anyone know what will happen if the patch gets applied for Mozilla-based
applications like Phoenix which link directly to libxpcom.so (the JAVA plugin
(1.4.0-b92) works for "phoenix-bin" without the patch - quiz is what will happen
with the patch applied) ?
apps that link against libxpcom.so donot use the standalone glue code and
therefore do not have any problem like this.
checkin cleared balsa (linux static) and Phoenix tinderboxen
if other problems arrise, please open new bugs

patch in trunk, marking FIXED.
Status: NEW → RESOLVED
Closed: 22 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.3beta
*** Bug 191088 has been marked as a duplicate of this bug. ***
Flags: blocking1.3b?
*** Bug 192657 has been marked as a duplicate of this bug. ***
verified
Status: RESOLVED → VERIFIED
What am I missing?   
 
xpcom/glue/standalone/nsXPCOMGlue.cpp is patched. 
   
I checked out the code from CVS and verified that the patch is indeed in the   
code.  But yet, when I try running mozilla, I still get this:   
   
LoadPlugin: failed to initialize shared library   
/usr/local/j2sdk1.4.1_01/jre/plugin/i386/ns610/libjavaplugin_oji.so   
[/usr/local/j2sdk1.4.1_01/jre/plugin/i386/ns610/libjavaplugin_oji.so:   
undefined symbol:   
GetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]   
   
I tried forcing libxpcom to be linked and preloaded with mozilla-bin, but   
still no luck.  Here are the nm and ldd outputs...   
   
cd /kurt/mozilla-cvs/dist/bin && ldd mozilla-bin    
        libxpcom.so => /kurt/mozilla-cvs/dist/lib/libxpcom.so (0x40013000)   
        libmozjs.so => /kurt/mozilla-cvs/dist/lib/libmozjs.so (0x40185000)   
        libplds4.so => /kurt/mozilla-cvs/dist/lib/libplds4.so (0x40218000)   
        libplc4.so => /kurt/mozilla-cvs/dist/lib/libplc4.so (0x4021c000)   
        libnspr4.so => /kurt/mozilla-cvs/dist/lib/libnspr4.so (0x40221000)   
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40267000)   
        libdl.so.2 => /lib/libdl.so.2 (0x4027b000)   
...   
  
cd /kurt/mozilla-cvs/dist/bin && nm -o --demangle libxpcom.so | grep -i  
GetGlobalServiceManager  
libxpcom.so:00104e5c T  
nsServiceManager::GetGlobalServiceManager(nsIServiceManager**)  
  
  
What am I missing if this does pass all the nightly build tests? 
I'm using mandrake x86 9.0 and here is my .mozconfig (not that all these 
options do anything) 
 
cd /kurt/mozilla-cvs && cat .mozconfig 
ac_add_options --disable-mailnews 
ac_add_options --disable-ldap 
ac_add_options --disable-freetype2 
ac_add_options --disable-postscript 
ac_add_options --disable-xprint 
ac_add_options --disable-jsd 
ac_add_options --disable-accessibility 
ac_add_options --disable-composer 
ac_add_options --disable-mathml 
ac_add_options --disable-tests 
#ac_add_options --disable-debug 
ac_add_options --enable-optimize="-g -O -march=pentium2" 
#ac_add_options --disable-dtd-debug 
#ac_add_options --disable-logging 
#ac_add_options --enable-strip 
ac_add_options --disable-strip 
 
ac_add_options --disable-gtk 
ac_add_options --enable-toolkit-xlib  
 
# Only allow png images. 
ac_add_options --enable-image-decoders=png 
ac_add_options --with-system-png 
ac_add_options --with-system-zlib 
 
 
ac_add_options --with-oji 
ac_add_options --enable-oji 
ac_add_options --enable-extensions=default,-inspector,-oij 
 
 
 
Thanks! 
-kurt 
Kurt, that's the standard "you built mozilla with gcc 3.x and Sun built java
plugin with gcc 2.x" error.

Reference dbaron's comment 5. This bug appears to have ONLY dealt with the
problem in comment 2, your error is the one in comment 3.

Blackdown have solved the problem in comment 3 by distributing two plugin
binaries, one compiled on each gcc version.

Sun has stated they'll provide a fix in a future release as well. (I suspect the
same fix as blackdown used.)

DougT's comment 19 and comment 35 seem to strongly imply that there is some
change coming down the pike that will allow a better solution. DougT: do you
have a bug number we can watch for that?
*** Bug 194601 has been marked as a duplicate of this bug. ***
*** Bug 191917 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: