The state of compilers in DragonFly and stuff
hasso at estpak.ee
Sun Aug 9 09:07:54 PDT 2009
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:
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 ... ;)
More information about the Users