Okay, that I was crazy is something that people knew after looking at me.. or at the herds I’m currently in 😛 (sound, video, kde …). But what I’m talking here is supreme crazyness 😀
It was a bit that I was wanting to try GCC 4.1.. quite after the first snapshot I’d say. Unfortunately it always failed on AMD64, so I left it “a bit of time” to fix itself; the last week talking with Halcy0n, it seemed like GCC 4.1 was at least stable enough to try it without sacrificing the newborns, so I tried it again and, surprise! It still failed on AMD64; me and vapier told Halcy0n the same problem, so it was not only my system being screwed up.
After a bit, and fights between binutils and gcc guys about who was doing the wrong thing, a patch came up, but it’s not yet committed. I wanted to try it anyway. I copied latest 4.1.0_beta20051112 ebuild on my overlay, and added the patch, GCC 4.1 compiled fine. Thanks to eradicator’s eselect compiler i was able to select the compiler without having to re-source the profile, and that is way useful 🙂
I tried it first with unieject and then with xine-lib, just to give a look to the problems of the programs I maintain directly. But then, I had KDE 3.5.0_rc1 waiting for me 🙂
Unfortunately I suddenly stopped in front of arts, as one of the patches, that adds -fno-stack-protector-all flag, was making GCC 4.1 fail (because that flag is not supported), so I reworked the logic of the ebuild to check which flags are enabled, to allow building arts with compilers such as vanilla GCC that does not have the -fno-stack-protector-all flag.
Now, I’m building KDE and it seems to go through safe, without big troubles for now. KMobile seems to be a piece of broken software, and it’s not even compiled by default kde, so I’m wondering if we should remove it entirely. The speed of GCC 4.1 is helping out, as kdelibs took an hour less than last time. I just hope the generated code has decent performance 😛 (possibly, better than GCC 4.0).
Oh I wish to thank Colin Lear for his help with the XSLT thingie and SeJo for letting me know I can both^Wask him if something else come up 😛
For who was wondering, the solution I’m using now is:
<xsl:template name=“block” match=“block”>
<xsl:param name=“id” select=“@id” />
<xsl:param name=“title” select=“@title” />
<xsl:param name=“content” select=“./” />
<xsl:attribute name=“id”><xsl:value-of select=“$id” /></xsl:attribute>
<xhtml:h1><xsl:value-of select=“$title” /></xhtml:h1>
<xsl:apply-templates select=“exslt:node-set($content)” />
using exslt function node-set() that creates the nodes starting from the string value. Now I can say I’m really separating the content from its visual style 🙂
Hmm… Didn’t you met the groff bug?When I’m trying to compile Gentoo on AMD64 with GCC 4.1, groff fails withinput.cpp:2369 error: ‘process_input_stack’ was not declared in this scopeinput.cpp:2370 error: ‘end_dicersions’ was not declared in this scopeinput.cpp: In function ‘void process_input_stack()’:input.cpp:2661: error: ‘title’ was not declared in this scope