From MozillaWiki
Jump to: navigation, search

libxul is a way of being able to link gecko apps, such that the core of gecko is almost completely within one shared library, "libxul".

Why move to libxul?

  • Firefox is using libxul by default.
    • and hence FF developers frequently break non-libxul configurations due to not building it.
  • OOPP and IPC require libxul.
  • Moves us closer to being a "pure" consumer of Firefox/gecko code (i.e. as close as possible without modifications to the core).
  • For xpcshell to run in packaged tests, we need a libxul or shared configuration.
    • Shared has various downsides:
      • It requires additional manifest entries and ifdefs
      • It isn't what we're actually shipping, so reduces the usefulness of packages tests to just spreading load across builders (which Thunderbird doesn't have a strong requirement for at the moment).
    • Therefore a libxul configuration for shipping and packaged tests would be much better because we will test exactly what we ship with minimum of configuration differences.

The one obvious disadvantage of libxul is that we'll go from a full-static to a shared-library build, and therefore we'll likely loose some performance as a result. However, for maintainability purposes going forward and the fact that work is being done on startup performance, having libxul seems like the far better option.

Libxul configuration

There are currently two ways we can set up a libxul style build:

  1. Gecko built into libxul, mailnews, mail as a separate shared libraries, built with the "frozen API" (aka "external API")
  2. Gecko, mailnews and mail built into libxul, mailnews built with "internal API"

Option 1 - Mailnews, mail as separate libraries

Note: This is pretty much the same configuration as xulrunner builds would be.


  • For developers, the mailnews specific libraries would be separate to libxul. This means they can still build core, and then just relink mailnews (or mail etc) during development.
  • This is the next step on towards xulrunner builds if we were to go that far in the future.


  • Linking with the external API means we loose a lot of the string optimisations that we get from the internal API.
    • e.g. nsAutoCString equates to nsCString in the external API, and so you won't get pre-allocated memory on the stack.
  • There would be multiple extra shared libs that will likely slow down start up performance.

Option 2 - Mailnews, mail included in libxul

There is some support in the mozilla-central build config for this already, it needs some extra work, but it is possible to do.


  • We keep the internal API that we have now, hence reducing the loss of performance.
  • Interfaces (e.g. libmime) would be hidden in libxul, we'd have to explicitly export them if add-ons want to use them.
    • Although in some ways I think this could be seen as a disadvantage because it is extra work to maintain and not so flexible for binary extensions; I could also see it as an advantage because we then know what non-xpcom interfaces binary extensions are using, and have some idea of the impact if we change those interfaces.


  • Developers would have to re-build mailnews and re-link libxul to be able to test changes (assuming shared configuration is also not supported).

Option 3 - Static libxul linked into Thunderbird executable

This is building core in the libxul style, but then linking it into the Thunderbird executable. Essentially this ends up the same build as what we've got now for static builds.

The way forward

Shipping Thunderbird set up as per option 2 seems to be the best way forward. It gives the best balance of future maintainability and retaining performance advantages.

However, it is still unclear if we want (or mozilla-central wants) to support a fully-shared build option. Given that this could get regularly broken anyway, it seems that supporting option 1 for developer use would be the best of both worlds, although there could be a little bit more work/pain. However, the existing use of macros with the frozen API, an upgraded try server and developer documentation would help to reduce the work/pain caused by the two configurations.

So the steps forward would be:

  1. Implement option 2 to include everything in libxul.
  2. Switch over production builds from being static to being libxul based, still supporting shared builds.
  3. (depending on what is likely to happen for shared builds) Finish work on the frozen API and fix any outstanding issues.
  4. (depending on what is likely to happen for shared builds) Support option 1 for developers, potentially dropping fully-shared build support depending on mozilla-central.

Tracking bugs

  • bug 585947 - Main tracking bug for libxul in Thunderbird work

Other related bugs

  • bug 432162 - Can't Build mailnews with libxul or XULRunner
  • bug 306324 - Build/run Thunderbird on top of XULRunner (dependency tree)
    • This is not a requirement for libxul (and not a current aim for Thunderbird), however the dependences are mainly required for option 1.