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.