What’s Coming for gtkmozembed
I’ve made a lot of progress recently with low-level libxul and embedding changes, and I’ve been needing to post about my plans for the gtkmozembed framework: I’ve already made commitments in the roadmap that the gtkmozembed code would be integrated into libxul, but but I never really said what I’m trying to accomplish:
- Define a recommended linking strategy for gtkmozembed: currently many distributions compile Mozilla with -rpath /usr/lib/mozilla-1.7.10 or whatnot, but this is a poor solution because it means that any embedder who uses gtkmozembed (Epiphany etc) is tied to a particular version of Mozilla, and distros have to recompile these apps every time there is a security release of Mozilla.
- Remove the necessity for any special environment variables such as MOZILLA_FIVE_HOME or LD_LIBRARY_PATH: the fact that you can’t set LD_LIBRARY_PATH and have it take effect in the same process is a particularly odious situation for embedders who actually want to use the GRE the way it was intended.
The solution I am going to implement fixes these problem by exporting the gtkmozembed API from within libxul. There won’t be any more “libgtkembedmoz.so” separate from the main libxul library, the symbols will be incorporated directly. This will allow gtkmozembed embedders (such as Epiphany) to link using the XPCOM glue and the new XUL glue functionality (agh, I need to document this on devmo!). They will no longer have to directly link against any of the mozilla libs, and therefore won’t be tied to a particular installation of XULRunner/Mozilla/whathaveyou.
The typical process for bootstrapping a gtkmozembed app will be something like this (in sketch form):
GRE_GetGREWithProperties("gtkmozembed=1");
XPCOMGlueStartup();
XPCOMGlueLoadXULFunctions("all those pesky gtkmozembed APIs");
gtk_moz_embed_set_path(the path from gre_getgre above); // instead of setting MOZILLA_FIVE_HOME, we tell gtkmozembed where we found it
Use gtkmozembed APIs the way you always would (no changes to the APIs)
When you're done:
XPCOMGlueShutdown();
This app will only need to link against libxpcomglue.a… it won’t need to (and shouldn’t) link against libxpcom.so or libxul.so or anything like that.
December 24th, 2005 at 4:17 am
There would be a great improvment if you’d allow the libraries to just go in /usr/lib instead of /usr/lib/ and use correct SONAMEs.
December 25th, 2005 at 10:37 pm
I presume you mean “/usr/lib instead of /usr/lib/mozilla-1.7.12”?
Traditional soversioning techniques are not compatible with mozilla’s versioning strategy: the APIs that we expose are for the most part not library symbols, but are rather vtable-based interfaces; many embedders (all the important ones) uses nonfrozen APIs; gecko is not a single library but a collection of interacting files; most importantly we want our apps (including their component parts such as xulrunner) to support relocatable install (avoiding hardcoded library paths) and be installable by nonroot users.
December 26th, 2005 at 4:14 am
I fail to see what this changes at all. If anything, this means that the SONAMEs should be changed often, or that some libraries should be glued in a single file.
Furthermore, proper versioning is the best way to achieve relocatable installs, as you don’t need RPATH or environment variable munging to make it work.
December 26th, 2005 at 4:17 am
What is the difference with Apache httpd ? It can use .so in an arbitrary directory defined in the configuration file without playing with LD_LIBRARY_PATH.
December 27th, 2005 at 5:41 pm
Hi Benjamin,
Thanks for the update. It would be nice if you could comment on http://bugzilla.gnome.org/show_bug.cgi?id=140713, which of these points are worked on, etc.
December 28th, 2005 at 12:00 pm
The difference between Apache and Mozilla is that the sharedlibs loaded by Apache are typically self-contained entities that don’t need support files. XULRunner, on the other hand, is a package that has many support files: these files cannot be “glued in a single file” because they are not all binaries with symbols, they include text/chrome JARs.
Please note that it not sufficient to have Firefox (or Epiphany or whatever the xulrunner client is) be relocatable, XULRunner itself must be relocatable such that unprivileged users can install new XULRunners into ~/.local if necessary.
January 9th, 2006 at 10:39 pm
sorry, but I really don’t get what gtkembedmoz has to do with libXul. Actually, I see GtkMozEmbed, for example, as the only way to run a “good” webbrowser (of course not complete at all) and just don’t care about XUL Could you explain better your point ? Why integrate it with libxul ? thanks
July 11th, 2006 at 3:01 am
[…] Applications using libgtkembedmoz.so will still have to use workarounds to be able to find the correct version of the library. (see Novell bug 184911) In most cases this workaround is using rpath. Please see what’s coming with XULRunner 1.9 in the future. Every application using gtkmozembed should use this linking strategy when XULRunner 1.9 is finally there. […]