Bugzilla Bug 214785

So I have Eclipse 3.3.1.1 installed and have configured swt to use xulrunner.
However, when I actually open an editor that attempts to make use of xulrunner,
I get an eclipse crash with the following on standard error:

/usr/lib/jvm/sun-jdk-1.6/bin/java: symbol lookup error:
/usr/lib/libswt-xulrunner-gtk-3347.so: undefined symbol: XPCOMGlueStartup

I've worked around/solved this problem by doing the following:

edit /usr/lib/pkgconfig/xulrunner-xpcom.pc and added -lxpcomglue after the
-lxpcom entry.

Effectively, getting the extra libxpcomglue.so to be linked into the
libswt-xulrunner-3347.so 

I have not noticed any negative impacts anywhere else....

Afaik this has nothing to do with gnome. I suspend this same kind of problem
that totem had at one point where libs using xulrunner didn't use the proper
pkg-config to link against (altough I grepped through the pkgconfig files and
couldn't find references to the glue stuff).

It was a toss up as to where to initially file this bug.  And I also could not
find a pkg-config that include the glue library, so I thought maybe the
xulrunner ebuild would need modification to either create a new pkg-config that
had the glue (that could then be used by swt), or just to always include the
clue in the current config. (I can't think of any problems this would cause)

This may have to do with the fact that we define a special variable on Eclipse
to point to some *.so libraries (MOZILLA_FIVE_STAR_HOME or something like
that). Currently this is hardcoded to the Firefox location IIRC. Changing that
to xulrunner could solve the problem

(In reply to comment #3)
> This may have to do with the fact that we define a special variable on Eclipse
> to point to some *.so libraries (MOZILLA_FIVE_STAR_HOME or something like
> that). Currently this is hardcoded to the Firefox location IIRC. Changing that
> to xulrunner could solve the problem

I don't see anything defined in the Eclipse ebuild itself, but it's defined in
swt ebuild and when build against xulrunner, points to xulrunner directory. GJL
launchers pick it, I doubt eclipse's does though. But somehow it used to work
until now, and it was xulrunner being bumped, not eclipse/swt?

Ah, found the startup script for eclipse. Yeah it sets the variable to firefox.
Should use what swt's package.env defines. Seems java-config doesn't provide an
option to query arbitrary variables from package.env of a package, only from
VM's env file... but this should work, will export MOZILLA_FIVE_HOME and a
harmless gjl_args variable...

eval $(gjl --package swt-3 --get-args)

And perhaps eclipse ebuild should check that swt is built against a mozilla
implementation because I think it won't work without it...

Created an attachment (id=148196) [edit]
patch for eclipse-3.3 script in FILESDIR (apply in
PORTDIR/dev-util/eclipse-sdk)

This patch implements this via gjl until we get less hackish support in
java-config (bug 216014).
Needs a revbump to hit everyone.

In 3.3.1.1-r1 in CVS.

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