I have two seperate reports of compiling mozilla-firefox-1.0.4 breaking XUL (none from myself), as seen in the attached URL. The two complaints have XUL broken in the file picker dialog and the preferences. The only thing that has changed since I installed mozilla-firefox-1.0.4 myself is the inclusion of the GCC 4 patch, and removing said patch fixes the issue Please look into what could be causing this. Reproducible: Always Steps to Reproduce: 1. emerge mozilla-firefox-1.0.4 2. 3. Actual Results: Some of the XUL dialogs should be broken Expected Results: The XUL dialogs should all act just fine
I can't seem to reproduce this, with gcc4 or gcc 3.4. Can you give the exact steps to reproduce this, and the output of `emerge info'? I can't see how my patch would affect this at all, but I don't know a lot about the structure of the Mozilla code.
Unfortunately, no - the problems were reported to me by users yaaar and sdousley from #gentoo on FreeNode. Removing gcc4's patch fixed the problem, I'm about to begin my own research.
Almost forgot - this isn't being built on gcc4, it's being built on GCC 3.3. And after looking at the patch, I'm inclined to believe this is really a problem with the user's config... perhaps distcc causing problems or ccache slipping up somewhere. If no-one else can verify this, mark as INVALID
I had the same problem. Rebuilding mozilla-firefox with the exact same settings / setup (GCC 3.4 and current ~x86, no ccache/distcc) worked. The error message was different too, altough I can't remember it anymore. I had the same issue on 1.0.1 where rebuilding helped too, so it's unlikely that it's caused by the GCC4 patch. It's likely a IO problem on their (and my) boxes.
Been experiencing the same thing here for a couple weeks, but just now got around to seeing if someone submitted a bug. Two times I know for sure when I get such errors (happens every time): - trying to access viewcvs on my local box. - trying to access r.g.o's mlmmj web interface. Let me know if I can do anything to help you guys solve this. Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-4.0.1-pre20050616, glibc-2.3.5.20050421-r0, 2.6.11.11 i686) ================================================================= System uname: 2.6.11.11 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.12 dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.16.1, 2.16.90.0.3 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/env.d /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/local/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect cvs digest distlocks sandbox sfperms sign strict" GENTOO_MIRRORS="ftp://gentoo.chem.wisc.edu/gentoo/ ftp://mirrors.tds.net/gentoo/ ftp://ibiblio.org/pub/Linux/distributions/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/buildroot" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/ka0ttic/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aim alsa apache2 bash-completion berkdb bzlib cdr crypt cscope esd fam fbcon gdbm gif gtk gtk2 imap imlib jpeg maildir mailwrapper mikmod mmx ncurses nls nptl offensive opengl oss pam pcre pdflib perl png python readline ruby sdl slang snmp sse ssl svga tcpd truetype unicode usb x86 xml2 xmms zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS, MAKEOPTS
Also, forgot to add. Unlike the picture most of my "syntax errors" are usually: type="text/css"?> -----^
seems to be a corrupt mozilla config. [close firefox] $ mv ~/.mozilla ~/.mozilla.old [start firefox] works.
So, this really isn't a fault of my gcc4 patch then? I don't see how it would be.
No, though the firefox ebuild probably should be written to delete the XUL cache on upgrading, to solve problems, but I'll file a seperate bug for that. For any users getting this, the workaround is to go to ~/.mozilla/firefox/[your_profile_directory] and delete XUL.mfasl - it will be regenerated by firefox on the next run. Resolving as invalid.
