Praise to firefox (or blame cairo, or praise cairo)

Lately I start getting firefox feeling quite slow, well sluggish from version to version. Today I started a discussion about that with Anarchy and nenolod, in 5 min we found out that the faulty lib was cairo and that the newer cairo snapshot makes things blazing fast again.

In short that is an apology to the firefox devs (and Anarchy) for thinking they are messing things up, a praise for the new cairo and a blame for the current stable one (once Cardoe’s wii addiction fades out probably we’ll have an updated ebuild to get the speedup)

PS:note even if you are fine with the current stable, the cairo .6 is quite suggested if you use boxes with different endianess and X over ssh ^^

Building on/for Cell/SPU

One of the most annoying things I’m starting to see are bogus way to check for presence of compilers or lib for SPU support…

Since it is almost the last day of the year here the top annoying pratices list:

– misnaming: ppu- isn’t a valid prefix, powerpc64-unknown-linux-gnu- is, anyway if is the native compiler gcc would do perfectly, if isn’t someone would provide it to configure so. PLEASE AVOID PPU-

– misnaming: spu- could be a partially valid prefix, _maybe_ spu-elf- is the correct one . TREAT SPU AS A CROSS TARGET, ALWAYS.

– bad assumption: I may have a valid spu compiler but _MAYBE_ I didn’t registered elfspe or elfspe2 on binfmt so I cannot automagically run spu binaries or maybe I don’t have spufs mounted. TREAT SPU AS A CROSS TARGET, ALWAYS.

– picking cflags from env: the spu-elf-gcc and the native gcc may not share the same cflags, make sure your configure could pick CFLAGS_{powerpc,powerpc64,spu} as they fit.

– hardcoding paths: the ibm and the sony sdk are for non native system with non default cross paths, I know beside gentoo and few other crazy people nobody is using alternate paths, still since maybe native system should be expected and _maybe_ less custom paths could appear, please do not hardcode /opt/${STI_SDK}/blah as include/lib path in your applications or applications patches (like the one for lame). PLEASE KEEP THINGS CLEAN.

Here a top5, luckly there aren’t that many annoyances =)

Have a great new year.

who cares about fortran?

Ok, flamebait title….

Now with the new newlib release I’m pleased to announce that I’m just 2 steps from having a working out of box spu toolchain.

all you need currently is just to:
– patch the toolchain.eclass https://bugs.gentoo.org/show_bug.cgi?id=158495
– disable fortran useflag (since it won’t build because of a upstream issue)

and then just issue a crossdev –l 1.15.0 –g 4.3.0_alpha20061216 spu

and you’ll have a a full toolchain (including spu-elf-g++)

Many thanks to my fellow testers and to Shine for the ssh account over his box =)

spe-samples builds!

Ok, it shouldn’t be a important news in itself but creating an ebuild for it helped me getting a better idea on which are the pitfalls and issues of:

– autotools usage: probably would be better avoid that many configure and call the spu ones as they were cross building
– paths and prefixes: ppu- and plain spu- aren’t that correct IMHO and seems config.sub shares my opinion…
– forcing -m{32|64} could be wrong when you try to embed spulets in ppc{32|63} elfs
– you shouldn’t feed spu-elf-gcc with CFLAGS_ppc64 …

Hopefully I’ll try to get some of those issues clarified from upstream and/or fixed in an eclass or in the toolchain.

Cell/SPU support almost there

Ok, well I think you already know that gentoo is working pretty fine on ps3 and we are working on getting a quick install route for it (basically figure better how kboot works and make it do what we want)

Today I eventually got a shell on a ps3 and spent some time fixing the libspe2 ebuild (testing it in first person eventually =)), you can find it in my overlay, to get SPU stuff working you need the _VERY_LATEST_ gcc binutils and newlib and just issue a crossdev spu –stage3 to have a (hopefully) good toolchain.

Many thanks to Shine, that is also already starting to code something useful (that I’ll rip for mplayer once I have the time to start working on it) http://forums.ps2dev.org/viewtopic.php?t=7209

In the other news I got the efika eventually and, well, it’s _really_ tiny, I bought a 60GB hd and I start gather the rest of the components to play with it, I hope next week to assemble everything and have something to tell even about it =)

Misc news

If you check the overlaytimeline you could see some minor updates (new libspe1 and ps3pf_utils tentative ebuild)

I hadn’t written much lately but quite a lot is happening on #gentoo-ppc64 thanks to quite a lot of ps3 owners willing to help testing and to ranger and JoseJX that are preparing something interesting (I won’t tell what since we are working on that right now and probably I’ll leave Brent the pleasure to be the first writing about it once it’s ready^^).

I’m still following what’s happening in the toolchain and kernel sides and looks like all the pieces are coming together nicely.

I guess that’s all.

PS: I read on a certain site complaints about having some patches to support ps3 merged in the .20 kernel and other complaints about not having access to certain features like the gfx right now.

Well, considering how the other PowerPC consoles aren’t supported at all and how hard the Sony+IBM people are working, I’d suggest you to quit complaining and be a bit more supportive… Maybe IF the experiment goes well IBM or Sony or Toshiba could come up with more Cell based hardware for the workstation/desktop market…