Xulrunner 1.9beta4 *not* approaching experimental

I appear to have underestimated the remaining work needed to get xulrunner in a pleasant enough shape for an upload. Which means the package won't be ready this week-end. It's always when you come closer to the goal that it gets farther...

And I still haven't decided once and for all if I would still version the libxul library. The problem is the following: there are two different ways to link or load libxul: dependent glue or standalone glue. The first one dynamically links embedding applications to both libxpcom and libxul, while the second links to a static library (well, dynamic, in Debian, because there is no reason why we should need to binNMU all reverse dependencies whenever we fix something in the glue), which dlload()s libxul. From Mozilla POV, embedding applications are supposed to use the standalone glue.

Considering we will more than probably have both schemes in use within reverse dependencies, I'm not sure I still want to bother diverging from upstream by keeping SO versioning on libxpcom and libxul... That unfortunately means that we will go back to the previously sucky situation where reverse dependencies have to put a dependency on the Gecko runtime themselves. A debhelper might help, though.

I will keep SO versioning on libmozjs, though, because it has some reverse dependencies, and a changing ABI.

The good news, anyways, is that I was able to build and run Iceweasel on top of the xulrunner pre-package.

I also ran sunspider on both this Iceweasel 3.0b4 and Iceweasel 2.0 ; the difference is really impressive: 3.0b4 is almost 4 times as fast !

For reference, the Webkit currently in unstable (which is quite old, actually), gives these results. The one in experimental unfortunately crashes. By the way, I'm planning to package a new Webkit snapshot soon after I'm done with xulrunner and Iceweasel, we'll see then how it performs.

While speaking of tests, both Iceweasel 3.0b4 and Webkit from experimental pass the Acid 2 test (contrary to Iceweasel 2.0), and have both quite good results on the Acid 3 test: 61 for Webkit from experimental, when it doesn't crash (but current trunk has been reported to score 91 !), and 67 for Iceweasel 3.0b4 (compared to 52 for Iceweasel 2.0).

Update: Interestingly, built with upstream optimization flags (-Os-freorder-blocks -fno-reorder-functions) instead of -O2, it is slighly slower, though it might be better on some older hardware, or other architectures (I'm testing on x86-64).

2008-03-16 00:06:02+0900

webkit, xulrunner

Both comments and pings are currently closed.

6 Responses to “Xulrunner 1.9beta4 *not* approaching experimental”

  1. Josh Says:

    Why not set the shlibs on the standalone dynamic library that does the dlopen to include a dependency on the version of the library it dlopens? Or something like that.

  2. glandium Says:

    Josh: because it doesn’t dlopen a specific libxul. It opens the one that corresponds to what the embedding application wants, and that could even be one the user had installed in his $HOME… it so much doesn’t depend on the libxul that the current xpcomglue in unstable (libxul0d provides one, already) can happily load libxul 1.9…

  3. asac Says:

    go the upstream way – #449448 :-P … the static glue is not a real life problem as its just a tiny layer that is unlikely to have grave issues within a debian support cycle.

  4. glandium Says:

    asac: the problem is not the dependency on the glue, but the dependency on libxul…

  5. Hrw Says:

    How does Ubuntu solved that? They have xulrunner 1.9 in repository.

  6. glandium Says:

    Hrw:

    Package: epiphany-gecko
    Architecture: any
    Depends: (...), xulrunner-1.9 (>= 1.9~b4), (...)

    Explicit dependency on xulrunner… yeah \o/
    And depending on what kind of data the application passes to GRE_GetGREPathWithProperties, the dependency has to be adapted. GRE-using application maintainers should better know what their application do with the GRE…

    By the way, according to the following:

    static const GREVersionRange greVersion = {
      "1.8", PR_TRUE,
      "1.9.*", PR_TRUE
    };

    a 1.8 GRE would work, but the dependency is too tight, actually. Though I have serious doubts about epiphany built against 1.9 working fine with a 1.8 GRE at runtime…