The state of compilers in DragonFly and stuff

[Hasso Tepper]

The gcc-4.4.1 was imported into DragonFly by corecode recently. I have to 
confess that it was probably my "fault" partly - I began discussion 
regarding this ;). There is two major issues with it though ...

At first corecode made -march=i686 default. It means that binaries 
compiled with it will not run on i486/i586 machines (which are supported 
by DragonFly) any more. I disagree with this because I think that 
compiler should generate (at least by default) binaries running on all 
supported machines. Note, that that's my main point. What we should 
support is slightly another story.

I don't mind dropping i486 support. Although it's still very much alive 
nowadays (cpu's are in production etc), it's relevant in the embedded 
world only. I'd argue regarding dropping i586 support (note, it's not 
only pentium, but also at least all Cyrix, VIA C3 and AMD K5/K6 CPU's). 
But if the comunnity agrees on this ...

Good relevant reading:
http://osdir.com/ml/redhat.release.psyche/2002-10/msg03258.html

Another issue is the state of pkgsrc. I didn't imagine that there is so 
much issues with pkgsrc. gcc 4.4 is much better at discovering potential 
strict aliasing problems (that includes in software using -Werror ;() and 
there was a major cleanup of c++ headers in gcc-4.4 development cycle 
causing major problems now while building c++ programs. There is probably 
more, these issues popped up as major ones doing partial pbulk build with 
400 packages I use on my desktops only.

I don't have resources (mostly time) to do so much work on pkgsrc and I 
don't see it coming from elsewhere either. NetBSD (as all other BSD's as 
well) have no plans to get any GPLv3 code into their bases, so no 
any "fix build with gcc-4.4" commits from there.

In short I don't see the chance to make gcc-4.4 default even after the 2.4 
release. We just can't break so much things.

Honestly, I don't know what position/direction we should take now ... ;) 
Thoughts?


-- 
Hasso Tepper