{"id":82,"date":"2006-02-22T18:28:14","date_gmt":"2006-02-22T22:28:14","guid":{"rendered":"http:\/\/benjamin.smedbergs.us\/blog\/2006-02-22\/debian-versioning-of-mozilla-libraries-harmful\/"},"modified":"2006-08-04T15:27:12","modified_gmt":"2006-08-04T19:27:12","slug":"debian-versioning-of-mozilla-libraries-harmful","status":"publish","type":"post","link":"http:\/\/benjamin.smedbergs.us\/blog\/2006-02-22\/debian-versioning-of-mozilla-libraries-harmful\/","title":{"rendered":"Debian Versioning of Mozilla Libraries Harmful"},"content":{"rendered":"

It has come to my attention that the maintainer of the Debian Mozilla packages (Mike Hommey<\/a>) is using patches that significantly alter the XULRunner linking strategy (first discussed here<\/a>).These patches cause various Mozilla libraries to be soversioned and installed in the library path (\/usr\/lib<\/tt>). Although I have emailed Mr. Hommey privately on a number of occasions, I have not received a reply, and the linking strategy that he has implemented is poorly thought out and will lead to instability and frustration.<\/p>\n

Background<\/h3>\n

On Linux systems, traditional shared libraries are installed into the system path (typically \/usr\/lib<\/tt>). In addition, there is a mechanism to support versioning, such that multiple versions of a library can be installed at the same time. This mechanism records information about the symbols provided by the library: incompatible changes are marked by a revision of the library’s major version number, backwards-compatible additions are marked by a change in the library’s minor version number, and minor bugfixes are marked by a revision of the micro (or release) version number. When an application is linked against a shared library, the version numbers are stored in the library and the dynamic linker ensures that when the application is loaded a library that is compatible is loaded.<\/p>\n

Mozilla is not just ABI<\/h3>\n

For libraries where the provided functionality matches the exported functions, this simple solution works well. But the Mozilla libraries are an entirely different situation: XPCOM libraries export a small set of frozen APIs, but the stability of these initialization and accessor APIs has little to do with the stability of the actual functionality provided by gecko (XULRunner). Almost all XPCOM functionality is exposed through interfaces, which are versioned using UUIDs<\/a>. As functionality is completed, these interfaces and the contractIDs that allow access to components are frozen, which guarantees that they will not change in future releases. Thus the functionality exposed by Mozilla is a set of frozen functionality exposed through interfaces, and a much larger set of nonfrozen functionality.<\/p>\n

XPCOM also has the ability to load an extensible binary XPCOM components: these components, if carefully written, can work with multiple versions of XPCOM and the various applications written on top of XPCOM. It is important that XPCOM components can continue to be compiled which work with multiple applications and versions. It is also important that when these component are loaded they use the XPCOM symbols from the currently running version of XPCOM library; if these components were to load an alternate XPCOM library, they would quickly crash or at least fail in unexpected ways.<\/p>\n

The Proven Solution<\/h3>\n

In order to allow multiple versions of XPCOM to coexist correctly on a machine, Mozilla has developed a linking strategy which allows applications to find a compatible version of XPCOM (XULRunner) and load it at runtime. This is called the standalone XPCOM glue<\/a>. The standalone glue linking strategy has the following characteristics:<\/p>\n