585944 - Make libxul capable of being a static library and linked into executables

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Mark Banner (:standard8)]

It has been suggested that libxul could be made to be capable of being linked statically, for the following reasons:

* Firefox could potentially link libxul into its own executable, thus reducing the number of libraries by one and potentially gaining performance (Note: I believe this is just an idea at this stage).

* Thunderbird and SeaMonkey could use this arrangement to do libxul style builds without having to go to external API and keeping everything in the executable.

This bug is for the investigations into making libxul a static library.

Comment 1

[(not currently active) Ted Mielczarek]

The patch from bug 525013 might be interesting, since that's exactly what it was doing.

Comment 2

[Robert Kaiser]

(In reply to comment #0)
> * Firefox could potentially link libxul into its own executable, thus reducing
> the number of libraries by one and potentially gaining performance (Note: I
> believe this is just an idea at this stage).

From what I read in tglek's blog, it might actually be faster to load a large libxul from a small app executable than having libxul be a part of a large static app executable.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

AIUI that's because having libxul as a shared lib allows the executable image to work around broken dynamic linker behavior, but I'm sure Taras could give a more thorough explanation.

Comment 4

[(dormant account)]

(In reply to comment #3)
> AIUI that's because having libxul as a shared lib allows the executable image
> to work around broken dynamic linker behavior, but I'm sure Taras could give a
> more thorough explanation.

Right. There are a few tradeoffs that need to be measured. On one hand one can do tricks to work around inefficient lib loaders, on the other hand those are turning out to be pretty tricky, so it may be best to do that from a static initializer in the static binary itself. More investigation is needed.

I think having an option of a single-binary executable is a good option to have, but at this point it's hard to quantify that as a win/loss.

Comment 5

[Mark Banner (:standard8)]

From what I can tell, we're unlikely to ever do this now. Thunderbird/SeaMonkey have not been heading to xulrunner style builds since it was dropped, and most of the could-affect-performance implications for Firefox have already been investigated in other bugs, and are unlikely to change.