Red Hat Bugzilla – Bug 201778
Eclipse misusing NS_InitEmbedding(): needs to use NS_InitXPCOM3()
Last modified: 2007-11-30 17:11:39 EST
Description of problem:
/usr/bin/java: symbol lookup error: /usr/share/eclipse/configuration/org.eclipse
.osgi/bundles/77/1/.cp/libswt-mozilla-gtk-3232.so: undefined symbol:
This is a blocker on Eclipse for FC6.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install eclipse-platform via yum
2. run eclipse
for f in `rpm -ql firefox | grep .so$`; do nm -D $f | grep NS_InitEmbedding &&
echo $f; done
for f in `rpm -ql mozilla | grep .so$`; do nm -D $f | grep NS_InitEmbedding &&
echo $f; done
00013ae4 T NS_InitEmbedding
*** Bug 202145 has been marked as a duplicate of this bug. ***
*** Bug 202292 has been marked as a duplicate of this bug. ***
*** Bug 202332 has been marked as a duplicate of this bug. ***
Adding as blocker for test3 and final.
*** Bug 205083 has been marked as a duplicate of this bug. ***
Trying to track down why this is no longer around, but in the meantime: do one
of the NS_InitXPCOM* methods do what you need?
Okay, more information. NS_InitEmbedding was an internal API that was never
intended to be used by anything other than Mozilla itself. The fact that it was
is an artifact from the old mozilla days. Moving forward, you need to move code
away from that. We have two options to fix this issue right for FC6:
1) Fix the Eclipse code to refer to NS_InitXPCOM3() and if Eclipse relies on the
auto component registration stuff that NS_InitEmbedding did, it should do that
itself with code such as:
nsresult rv = NS_GetComponentRegistrar(getter_AddRefs(registrar));
if (NS_FAILURE(rv)) return rv;
rv = registrar->AutoRegister(nsnull);
2) Add an extra step to the mozilla build process to add NS_InitEmbedding and
co. into a static library which Eclipse can link against. This seems to be
possible by doing some make file hackery.
Option 1 makes the most sense long term and I think we should aim for that....
Moving over to eclipse and re-summarizing...
(In reply to comment #7)
> 1) Fix the Eclipse code to refer to NS_InitXPCOM3() and if Eclipse relies on the
Thanks for the information. We have a patch that appears to work and we're
trying a full build now. Hopefully this will make it into rawhide tomorrow or
the next day.
Yeah, thanks for the info.
Andrew, things seem to be working OK. There's a browser in Window -> Show View
-> Other -> Genereal and the only problem I found was that slashdot crashes
Eclispe. Unfortunately no useful information is printed so we'll need to debug
that. I browsed around to some other sites and things seem to work besides the
slashdot thing so I ended up pushing a build (3.2.0-5).
The fix just hit dist-fc6 but I'm keeping the bug open because of the problem
with slashdot mentioned above. Removing FC6Blocker and FC6Test3Blocker because
Eclipse now starts.
I'll note that NS_InitEmbedding used nsILocalFile, and NS_InitXPCOM3 uses
nsIFile which could be a reason for crashes since it looks like you aren't
changing what gets passed to it.
Mozilla reference page:
Created attachment 137082 [details]
backtrace when attempting to view slashdot
I managed to attach to an SWT browser example using gdb and this is the stack
trace that I got. It was when it was loading slashdot.org. I got a similar
trace for osnews.com and I'll post that next.
Created attachment 137083 [details]
backtrace when attempting to view osnews
No, you should be using NS_InitEmbedding. When building libswt-mozilla-gtk, you
should link in the libembed_base_s.a; this provides the NS_InitEmbedding method.
You can get that library from the SDK
We had this working a while ago (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61384). What changed to cause
This is fixed in our RPMs > 3.2.1-3.fc6. I will track this upstream for 3.3.
(In reply to comment #16)
> No, you should be using NS_InitEmbedding. When building libswt-mozilla-gtk, you
> should link in the libembed_base_s.a; this provides the NS_InitEmbedding method.
Javier, Mozilla 1.7.13 has many outstanding critical security issues.
Additionally, static libraries are considered evil, especially in
security-ridden software such as Mozilla, which has a new security update nearly
every month, which fixes as many as 30 critical issues. See
http://people.redhat.com/drepper/no_static_linking.html. So, We don't and won't
Additionally, NS_InitEmbedding was never intended to be for embeddors to be
used, and it was unfortunate that it was available for application embeddors in
the first place -- an accident according to Benjamin Smedberg. Feel free to
talk to bsmedberg from the Mozilla Corporation for more details.
I've verified this fix on i386, x86_64, and ppc. I will try other architectures
if I can get access to hardware.
Eclipse now seems to work on Intel Mac's.