Reducing the libxul export list

In a (very hacked up) local tree, I’ve got the export list from libxul reduced to something almost-reasonable: 619 exports on win32 and 793 exports on linux. Quite a few of those are XPTCStubBase and can be removed, and there’s also some zlib and NSS symbols which I haven’t figured out how to hide yet. But we’re getting closer!

Atom Feed for Comments 4 Responses to “Reducing the libxul export list”

  1. Darin Fisher Says:

    So, is XPTCStubBase and the rest of the xptcall system going to be available in the form of a static library? Or, is it going to be exposed in some other way so that someone could create a new language binding for libxul? Personally, I’d prefer to see some stable API exposed by libxul (or better yet, via libxpcom).

  2. Jonathan Watt Says:

    /me cheers bsmedberg on

  3. Ilya Konstantinov Says:

    How to hide? In gcc, through a linker script. Here’s an example:
    (you might want to make your logic reverse – global * and local a bunch of zlib and NSS symbols)
    And here’s the changes to the Makefile:

  4. Benjamin Smedberg Says:

    Darin, I’d like xptcall to be made available as frozen exports from libxul. I don’t have a good handle yet on what that actually entails: do the current xptcall users link against the XPTCStubBase symbols (which are mangled C++ and therefore not freezable), or just the C function symbols?

    Ilya, linker scripts don’t actually provide the runtime benefits of symbol-hiding: if the compiler knows that the symbol is hidden it can avoid calling the symbol through the PLT, which in many cases means that the function doesn’t need to load the PIC register at all. See for more details.

Leave a Reply