[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gcc 3.x with Openbsd src tree
- To: "Ted Goodridge, Jr" <email@example.com>
- Subject: Re: gcc 3.x with Openbsd src tree
- From: Marc Espie <firstname.lastname@example.org>
- Date: Thu, 6 Feb 2003 12:31:41 +0100
- Cc: email@example.com, firstname.lastname@example.org, email@example.com
- Content-Disposition: inline
- Mail-Followup-To: "Ted Goodridge, Jr" <firstname.lastname@example.org>,email@example.com, firstname.lastname@example.org, email@example.com
- References: <001f01c2cb47$c5427a60$0500a8c0@vulcan>
- User-Agent: Mutt/1.3.28i
On Sun, Feb 02, 2003 at 11:47:42PM -0600, Ted Goodridge, Jr wrote:
> Yes, I know this is unsupported, but I'm not asking for help getting this to
> My question is:
> I know OpenBSD is eventually moving to the 3.x family of compilers of gcc.
Define `eventually'. From my vantage, it's getting more and more doubtful.
> Is there anything that I can do to help report bugs that would actually be
> useful for developers? Is there even a way to compile the OS with a series
> 3.x compiler?
Yep, it's possible.
What you can do is play with gcc snapshots, build them with profiling, and
figure out where that pile of sorry mess for a compiler loses its time now.
gcc 3.2.1 is TWICE AS SLOW as gcc 2.95, and the more recent development are
It's been a while now, and all we get from the gcc people is that `the next
version will be better'. They've been playing this game for years, and the
next version NEVER is better.
It's always slower. It always breaks on anything that is not intel-linux,
and it always takes forever to fix. It's very hard to `play ball' with
them because they are really not concerned at all with OpenBSD... or
with older arches like m68k, m88k, etc.
Yep, we need more people. There are just a few of us with time to spare
to play with the FSF, and this is a very tiresome game.
You have to realize that the linux distros pay a few persons FULL TIME to
work on gcc... It's no wonder they still manage to go forward and we