The term “GRE” is shrouded in mystery and especially on linux there is no good definition of what a GRE actually is (or was). I have written a couple of Mozilla Developer Center documents on how to use the GRE (dynamic linking and the standalone XPCOM glue), and how GREs are registered.

I’d like to make a few clarifications of terms that have been floating around:

GRE

Gecko Runtime Environment: the “platform” parts of Mozilla, which is registered with the operating system in such a way that embedders can dynamically link against it without knowing in advanced where it will be installed. This was shipped with the windows installers of Mozilla 1.4 to 1.7, but technically has never been shipped on Linux. Red Hat has shipped GRE-registration files that make the Mozilla installation into an embeddable GRE. XULRunner is the new product that will be the GRE.

XRE

XUL Runtime Environment: this is the term that was floated for a long time to be an framework to launch XUL applications. It has morphed into XULRunner, and there really isn’t any reason to use the term XRE any more (there never was anything that we shipped as an XRE).

XULRunner

XULRunner is a product that will serve as the installable Mozilla platform. It will be a GRE with embedding services, as well as a bootstrap mechanism for launching rich-client applications like Firefox. Firefox 3 will be built atop XULRunner and will be the primary distribution mechanism for XULRunner.

LibXUL

LibXUL is a implementation detail of XULRunner. It is a dynamic library containing all of “gecko”. The real benefits of libxul are that we only export frozen symbols from it, and that we can perform various optimizations such as minimizing the effects of the PLT.

There is a bug in GCC 4.0 (and 4.0.1 and 4.1) which breaks the Mozilla/Firefox/Thunderbird build on x86_64 and various other processors: GCC is treating the builtin functions such as “memset” and “memcpy” as having hidden visibility in certain circumstances that are hard to figure out. GCC bug 20297 covers the issue, though the patch in the bug doesn’t fix all the problems and I haven’t seen any action by the GCC maintainers to get the patch landed or fixed. I tried to provide a patch to detect this bug in Mozilla bug 307168, but apparently my configure test is not good enough to catch all instances of the bug.

In the meantime, if you experience the error “relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5′ can not be used” or something similar while building mozilla, use the following hackaround:

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!)

One of the most frequent and persistent complaints about XULRunner is that I have explicitly excluded support for client/server SQL databases. Some have even gone forth to say that lack of proper database access in the platform will be it’s Achilles’ heel. And so I’m going to try and address this issue head-on:

XULRunner does have a database strategy: the platform will provide support for a SQLite embedded database API reflected into XPCOM. It will not include support for client/server database mechanisms such as MySQL/Oracle/etc. This reasons for this are fairly simple: The primary targets of XULRunner are twofold: support the Mozilla rich-client apps (Firefox and Thunderbird); and allow innovation of networked rich client apps based on web technologies. Client/server databases really don’t have any part in this strategy; Mozilla would not have any real testing/QA framework for this code if it were included. We need to keep a lean and focused platform that does not try to solve everyone’s problems.

Having said that, there are a couple solutions for doing client/server database access:

1. Jan Varga has done client/server database code which lives in extensions/sql. If an app really needs client/server database access, it can ship the SQL extension with the application; I’m going to work with Jan to get this code into shape as a real platform-level extension and make it available on http://addons.mozilla.org/.
2. It’s not that hard to write a web proxy which takes SQL, performs a query, and returns the results as XML: AJAX-style web apps could use this to perform SQL-based queries over XMLHttpRequest. This will be even more useful once Neil Deakin completes the template work.

I’ll have a few cool XULRunner demonstrations up shortly, including a popular AJAX-style webapp in it’s own XULRunner process (hopefully with minimize-to-tray and everything), and the beginnings of some dashboard-like widgets written in XUL+SVG that are loaded directly from the web and have web-based security permissions.

The Linux installer for Firefox is terrible:

1. It is not packaged as a self-extracting executable, but a tarball that the user must manually unpackage before running;
2. It doesn’t provide any extra value compared to simply unpacking a Firefox tarball:
   • No OS integration;
   • No shortcut generation.

For these reasons, and because nobody has stepped up to create l10n repackaging of the Linux installer, I believe that we should not ship the Linux installer for Firefox 1.5, and I have filed a bug to that effect (bug number to remain hidden to avoid spammage). If you disagree with my decision, please email me directly and let me know why (and how much work you’re willing to do to make the Linux installer actually useful).

It is now possible to use XULRunner to install XUL applications in an OS-appropriate manner. The code for Mac is already checked in, and the code for Win/Linux is under review in bug 306689. This was most important on Mac, because unless there is an application bundle for the XUL application, the UI is basically nonfunctional.

To install a XUL application which you have in a ZIP/XPI file:

Mac

/Library/Frameworks/XUL.framework/xulrunner-bin -install-app /path/to/my/application.xpi

Windows

/Path/To/xulrunner.exe -install-app /path/to/my/application.xpi

Linux

/path/to/xulrunner-bin -install-app /path/to/my/application.xpi

It is also possible to install directly from an unpacked directory (xulrunner-bin -install-app /path/to/my/unpacked-application). But please note that the INI file must be called “application.ini” in the root of the XUL Application package, it may not be named “chatzilla.ini” or any of the other custom filenames that have been floating around.

Next steps:

1. GUI installer to drive the same process
2. Developer-mode process that uses symlinks instead of actually copying the files (mainly useful on Mac).

Robert Accettura writes

… You can have a ‘feature’ like Microsoft Office’s Mail Merge. It’s messy, has an awkward UI, and doesn’t always behave as the user would expect. It’s often considered to be one of the worst features in the entire suite…. I think that’s an example of the ugliness Asa hope to rip out (though different product [sic]).

I seriously hope that Robert wasn’t for one second suggesting that Microsoft Office ought not have mail merge. Mail merge is one of those daily activities in some environments that absolutely is part of a complete word-processing/office solution. You can’t just go around removing features because they have byzantine or even terrible UI. Features, even features that are only going to be used by 20% of the user population are necessary to sell a product. The trick is not to remove features, but to make their use as painless as possible for the people that need them, and as invisible as possible for the people that don’t.

At the same time, it is extremely important to understand that that Microsoft Office and Mozilla Firefox are in very different classes of software. A web browser is primarily a platform so that web content can do it’s stuff. All the fancy bookmarks and history integration planned for Firefox 2.0 is not there because users want fancy-pants bookmarks, it’s there so that the user can get to what they actually want to be using (the web) faster and better.

Neil Deakin points out a well-done parody of platforms and frameworks. Which got me to thinking: how is XULRunner different from these megalithic platforms? The most important part is that we’re not trying to do everything. In fact, one of the most important parts of my job is deciding what’s out. This is a balancing act, but I try to use these two guidelines to shape my decision:

1. Would most XUL apps use this feature?
2. Is it something that couldn’t be done as an extension or reusable application code?

If both questions come up “yes”, I am much more inclined to take a feature than if either answer were negative. For example, I am seriously considering incorporating the binary bits of DOM Inspector into XULRunner, as well as the binary bits of Spatial Navigation. Both of these features are tightly linked up with the gecko internals and there are some good ways that they can be reused.

I have rejected other features for similar reasons: generic SQL support is out (integration with MySQL and other databases) because it’s easy to build as part of your application and because it’s not likely to be generally useful.

I am not a skilled graphic artist. This is by no means a “final” XULRunner logo. I just created it in my spare time and it is a lot of fun:

In case you don’t remember your Greek mythology, Atlas was condemned to bear the heavens upon his shoulders by Zeus as punishment for leading the Titans in their war against the gods. I thought that the idea of holding up the Firefox globe was a fitting visual metaphor for XULRunner.

I will be on vacation from this Friday (16-September) through the next week on the outer banks of North Carolina; I’ll return on Monday, 26-September. I do not intend to check e-mail at all during my vacation… If you need reviews for patches targeted at the 1.8 branch, please request them ASAP.

This week Mozilla bought be a brand-spankin-new uber-powerful computer. I’m still getting to love it’s wonderfulness. I rearranged my machines so that the new machine (dual Athlon64, 4gig RAM) is running WinXP, my former Windows machine (Athlon64, 1gig RAM) is running FC4 (x64_64), and I’m going to retire my rather ancient Athlon1.2gig box which is running RH9.

The new Fedora Core has been giving me fits. First of all I couldn’t get the DVD image burned until the fifth try, for unknown reasons. Then the anaconda installer didn’t like some combination of custom install options I gave it. I finally broke down and told it to do a default “Workstation” install, and it finally installed.

Next, I tried to get both of my video cards to work in this machine. No dice. If I set the AGP card as the primary card in CMOS, I can’t get the secondary (PCI) card to display anything at all. If I set the PCI card as primary, I can get it to show up the first restart, but after that it doesn’t work again. Funnily, occasionally the boot sequence tells me that it found new hardware, please enter my root password. But I can never seem to enter it correctly…

Now, I’m running into the GCC 4.0 bug where hidden-visibility symbols are not compiled correctly, leading to the following error:
/usr/bin/ld: jsapi.o: relocation R_X86_64_PC32 against `memset@@GLIBC_2.2.5′ can not be used when making a shared object; recompile with -fPIC
Shaver said that this bug was fixed on the gcc4.0.x cvs, so I tried to build GCC from CVS. I can’t. I try the following configure steps:

CFLAGS="-m64" ../4.0.1-branch/configure --prefix=/builds/gcc/4.0.1-branch-installed --enable-languages=c,c++ --host=x86_64-redhat-linux --enable-shared --enable-__cxa_atexit --with-system-zlib

Compilation fails after a while with the following error:

./xgcc -B./ -B/builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/bin/ -isystem /builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/include -isystem /builds/gcc/4.0.1-branch-installed/x86_64-redhat-linux/sys-include -L/builds/gcc/4.0.1-branch-objdir/gcc/../ld -O2 -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. -I32 -I../../4.0.1-branch/gcc -I../../4.0.1-branch/gcc/32 -I../../4.0.1-branch/gcc/../include -I../../4.0.1-branch/gcc/../libcpp/include  -m32 -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
   -c ../../4.0.1-branch/gcc/crtstuff.c -DCRT_BEGIN \
  -o 32/crtbegin.o
In file included from /usr/include/features.h:337,
                 from /usr/include/stdio.h:28,
                 from ../../4.0.1-branch/gcc/tsystem.h:90,
                 from ../../4.0.1-branch/gcc/crtstuff.c:64:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

Does anyone know why, when I configured explicitly with -m64, it is still compiling with -m32 and looking for the 32-bit headers (which do not exist on this system)?

Update: 7-Sep-2005:

A helpful soul (pinskia) on irc.oftc.net/#gcc told me to use –disable-multilib and I seem to be in business. I would still like to figure out what I would need to install to get multilib working. Obviously redhat has multilib.