In bug 452232 I have recently been granted review on a patch which
component can be enabled via the
--enable-incomplete-toolkit-ldap-autocomplete configure option. Note
that so far the component only provides basic autocomplete
functionality, so it cannot yet be considered as a replacement for our
The advantage of this component is that it uses the toolkit autocomplete
interface, thus making it possible to remove some old XPFE autocomplete
code from the build, and potentially making it possible to build
Thunderbird without using XPFE autocomplete at all, however I don't know
whether anyone has looked into that possibility yet.
Additionally this helps us creep ever closer to being able to build with
external linkage. The remaining issues to building with external linkage
are as follows:
* LDAP autocomplete still uses some code that we currently link into
libxul. If you want to build with external linkage but without
in bug 707305 which you can apply to build the autocomplete
component with external linkage. (The patch does not affect
* In bug 560772 Callek checked in a patch that used a method that is
exported by a library that we don't link to yet; a patch to fix
the linking has been reviewed but not checked in yet.
* In bug 491843 IanN checked in a patch that used a method that
isn't available with external linkage; no patch to fix this has
passed review yet.
* The new mail notification used by Thunderbird on Windows uses a
method that isn't available with external linkage; I don't know if
a bug has been filed on this.
As well as not building out-of-the-box, the other disadvantage of the
external linkage builds is that they are probably slower to run. So, why
might you want to build with external linkage?
* Changes to mailnews C++ files don't require relinking libxul.
* Linux distributions may be interested in shipping several Gecko
applications built with the same libxul SDK.
* Yesterday I checked in a patch to allow
--enable-incomplete-external-linkage to work without using