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 attachment 148196 [details, diff] 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. ***
