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:

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):

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:

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.

Atom Feed for Comments 8 Responses to “What’s Coming for gtkmozembed”

  1. glandium Says:

    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.

  2. Benjamin Smedberg Says:

    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.

  3. Josselin Mouette Says:

    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.

  4. skc Says:

    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.

  5. Reinout van Schouwen Says:

    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.

  6. Benjamin Smedberg Says:

    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.

  7. Antonio Gomes Says:

    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

  8. Wolfgang’s blog » Blog Archive » The Mozilla Platform on SUSE Says:

    […] 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. […]

Leave a Reply