The Firefox-on-XULRunner build system is basically in place now: it can produce working builds on Windows and Linux with a couple special configure flags. I even have a set of changes that allow it to be built on tinderbox. Get your hot-off-the-press Windows build here! Note, this was built with MSVC7.1 and you’ll need to already have the runtime libs on your system.

I won’t post Linux builds because my Linux box is x86_64 and is totally hacked up anyway.

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!

A while back, I posted a workaround that lets Mozilla compile and link properly, working around a bug that is present in GCC 4. I am happy to report that the GCC bug has been fixed on the GCC trunk, 4.1 branch, and 4.0 branch (it should appear in GCC4.0.4 and 4.1.1). I was very excited and immediately went off to build my own GCC and try to build XULRunner with it. No dice! Linking failed in toolkit/library with a similar error as before:

relocation R_X86_64_PC32 against `nsINIParser::Init(nsILocalFile*)' can not be used when making a shared object; recompile with -fPIC

This might look at first glance like the same bug as before, but it’s not: the previous bug was about builtin functions like memcpy, while this bug is about class member functions. It is apparently some bad interaction between #pragma GCC visibility push(hidden) and a class-level attribute which is supposed to override that for default visibility. I managed after several hours of tedium to reduce the testcase to a 30-line .i file and have filed the bug with GCC.

For the moment, though, it appears that GCC4.0.4 and 4.1.1 will not be able to compile Mozilla without the same hacks as I suggested previously:
Configure with the following variable set:

ac_cv_visibility_pragma=no path/to/mozilla/configure –enable-options-here

or put this in your mozconfig:

ac_cv_visibility_pragma=no (Don’t prefix this with ac_add_options!)

Part of the XULRunner planning is not only to release builds of the XULRunner runtime platform, but also to produce and release a set of developer tools, which for lack of a better name I have been calling the XULRunner SDK, or XDK for short.

Several characteristics distinguish the XULRunner SDK from the currently released Mozilla SDK packages: (more…)

Suzanne and I are pleased to announce the birth of Abigail Porter Smedberg, born at 3:38 p.m. EST on Tuesday March 7^th: 8 lbs. 1 oz., 19 inches long. All are well. (more…)

I’m expecting a new baby tomorrow (she will be induced if she doesn’t come out naturally), so starting today I will be taking a two-week paternity leave. I’m not going to disappear completely, but I don’t expect to be doing any serious coding or reviewing for the next few weeks. The following peers are around to do urgent reviews in my absence:

• Build-config: Mark Mentovai or Bryan Ryner
• Embedding: Boris Zbarsky or Darin Fisher
• gtkmozembed: Crispin Persch (chpe@gnome.org)

I promise, I’ll post pictures of the new baby when she arrives!

IBM today released the first version of their AJAX Toolkit Framework, a plugin for the Eclipse IDE that allows developers to develop, inspect, and debug web applications. What is very cool about this project is that they are using XULRunner (with its builtin JavaXPCOM embedding support) to drive the web technologies.

I suppose that I’ll need to get to work creating user-friendly installers for XULRunner now. The current instructions instruct users to install XULRunner using the command line --register-global command-line flag, which isn’t very user-friendly.
Screenshots courtesy of Javier Pedemonte:

It has come to my attention that the maintainer of the Debian Mozilla packages (Mike Hommey) is using patches that significantly alter the XULRunner linking strategy (first discussed here).These patches cause various Mozilla libraries to be soversioned and installed in the library path (/usr/lib). 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. (more…)

Brendan proposes to break XPCOM reference cycles using cycle-detection algorithms.

I must admit that I’m skeptical: in order to break reference cycles you need to know what strong references an object is holding: to do that you either have to ask the object (which must implement a special interface), or you have to have special knowledge about the internal form of an object (presumably provided through some specialization of classinfo).
IMHO it would be a better use of our time and energy to develop a mark-and-sweep garbage collection for XPCOM objects: (more…)

Brendan claims that the XPCOM nsresult return type is a significant cause of bloat due the need to rv-check every XPCOM method call, and proposes that XPCOM switch to use C++ exceptions. This is an idea that might appear attractive on the surface but would not only break the existing binary compatibility of XPCOM but would permanently destroy XPCOM as a component model with a standard binary API. (more…)