Gentoo/MIPS Status Update
Monday, July 16th, 2007Hi All…
Figured I better let you know what’s happening from where I’m sitting, since it’s been a while.
Mozilla Package Support on MIPS…
For the past month or so, I’ve been faced with a few problems. Firefox 2.0.0.4 has decided to not compile, despite 2.0.0.3 working fine … It would appear I need to re-jig this MIPS patch so that it works with the updated codebase. The patch I specifically refer to is the 006_mips-asm.patch file that you’ll notice included in all the patchsets distributed with Firefox and Thunderbird. Without it, Mozilla uses assembly code specially crafted for the Sony Playstation II — an incompatible machine to just about every other MIPS machine in existence.
Thunderbird has its own problems too. People may have noticed -mips KEYWORDS on the 2.0 series and my refusal to mark >1.5.0.8 stable? Seems there’s a bizzare bug that only happens to me on big-endian MIPS (mips-unknown-linux-gnu) when talking to my local IMAP server (running B-Inc IMAPd 1.2.12). On little-endian MIPS (mipsel-unknown-linux-gnu), everything works flawlessly. Indeed, I’ve been using Thunderbird 2.0 on mipsel for the past few months without issues… if mipsel was our only architecture, it’d be keyworded in a heartbeat, but it’s not. The problem manifests itself in two ways: one is the apparent non-existant mail folders, the other is hanging in an infinite loop apparently switching folders. I’ve tried strace and other tools to no avail… but my biggest problems revolve around my (big-endian) boxes being quite slow and my limited time. Needless to say… I’d appreciate others’ comments on this issue if they’ve experienced these problems with Thunderbird, or if indeed, it works on their SGI box.
Adventurous users can try it for themselves by editing the relevant ebuild directly and running ebuild foo.ebuild digest before attempting a merge.
Gnome packages…
I’ve began trying a test-compile of Gnome 2.18.0 on MIPS lately… largely to see just how much of it is actually broken. Unsurprisingly, much of it failed in N32… mono being one spectacular failure: it got stuck in an infinite loop and filled up the disk printing debugging output, which of course portage logged in the package’s build.log. My O2 is busy doing many of the package builds here, progress being quite slow. Needless to say, there’ll be updates on the situation as I get each part built. I strongly doubt this will lead to a re-keywording of Gnome on MIPS however, because frankly, it’s a pain in the arse to maintain.
Possible support for Loongson on the horizon…
This is the first time I’ve discussed this on Gentoo Planet… Others may recall seeing my Gentoo Universe post talking about my usage of a Lemote Fulong minicomputer… No official decision has been made at this time, but behind the scenes work is already underway to allow support for this architecture under the Gentoo/MIPS banner. This is the box that I’ve been doing much of my little-endian testing on, since a 660MHz Loongson 2E will outperform a 250MHz RM5231 any day. Ultimately, I’d like to see this machine become officially supported, as I suspect it’ll be machines like this that will keep the MIPS port alive. The SGI boxes currently supported will eventually fail, and as the pool of parts dries up, so will our users.
At present, these boxes can be made to run Gentoo no problem. You need a small patch for xorg-server to prevent a nasty segfault when starting X, and of course, the kernel needs some patches that are not yet in mips-sources (or upstream). Work is being done in an overlay hosted by Lemote for now, but as soon as I get the official go-ahead, I’ll start moving things into the main Gentoo tree.
glibc upgrade issues…
Some users have reported issues when upgrading to glibc-2.5, essentially the build seems to cause hard-locks on some IP28 and IP30 users (me included). Work is still ongoing to track down why this occurs — as always though, feedback would be appreciated.
Cobalt IDE-related issues…
On later mips-sources kernels, some users have reported kernels failing to detect their IDE HDDs. I haven’t been able to test since 64-bit kernels are broken (I run a 64-bit kernel on my Qube2 for N32 testing) in other Apparently the issue is related to hotplug support — yes, despite the machine having no hot-pluggable interfaces, you still need hotplug in your kernel. People may want to look into moving across to the newer VIA PATA driver too, since I suspect the upstream kernels will start moving this way anyway — the newer driver is quite stable on Cobalt. More info in this forum thread.
If I think of anything… I shall post more later. 