An Incremental Path to libxul

Authors: Benjamin Smedberg and Darin Fisher

libxul is one of the core elements of the Mozilla 2.0 planning effort. It is a library that provides frozen API for XUL apps and embedders of gecko. The end-goal is to provide a library that only exports frozen symbols. This does not mean that all the *interfaces* would be frozen, but only that the link-time symbols would be few, well-defined, and frozen.

Right now the ordinary mozilla build has many shared libraries, both "components" and "dependent libraries" that make up gecko. libxul intends to replace this mix of shared libraries with, a static build of "gecko" including XPCOM, networking, DOM, layout, rendering, and embedding modules in one shared library.

It would be madness to attempt a dramatic change in our linking strategy and build system all at once. The gameplan needs to involve gradual changes to the build system and linking strategy.

In addition, some (many?) developers of mozilla do not have the RAM to make a static build of gecko a fast and efficient operation. There should be a build option that maintains many of the shared libraries separately.

The Incremental Game Plan

1. Already completed: combine libs from tier 1/2/9 into one "libxul". This does *not* include libmozjs.so, which does not depend on the XPCOM lib. See bug 274605 for the latest patch.
2. Use the GCC 4.0 per-class hidden-visibility attributes to ensure that all symbols are hidden unless they are explicitly supposed to be exported. See bryner's work in bug 273336
3. Add in the rest of tier 50. This does not include some component libraries that use runtime dependencies which may not be installed on the end-user machine (gnome-vfs and the gnome icon decoder are the most interesting examples).
4. Stop exporting the string library! This will require some (significant) changes to the apps which are built on top of gecko, requiring them to link against the frozen string library or a shim to it.

Appendix A: Maintaining the Developer Build

In step 5, above, we stop exporting the gkgfx symbols. This would break the developer build unless there were special arrangements. The special arrangement is a NS_DEVEL_EXPORT macro which only exports these symbols in developer builds (this can be hooked into the existing NS_GFX macro and others as appropriate).