From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: hjl@lucon.org (H . J . Lu) Cc: aj@suse.de (Andreas Jaeger), geoffk@redhat.com (Geoff Keating), gcc@gcc.gnu.org Subject: Re: Compiler for Red Hat Linux 8 Date: Wed, 18 Jul 2001 12:01:00 -0000 Message-id: <200107181901.MAA06972@atrus.synopsys.com> References: <20010718090333.A11375@lucon.org> X-SW-Source: 2001-07/msg01290.html On Wed, Jul 18, 2001 at 11:41:18AM +0200, Andreas Jaeger wrote: > > I personally would appreciate - and support - a commitment from some > > of the Linux distributors on the next GCC version they're using and on > > compatibility to a *released* GCC version. HJ Lu wrote: > I think that is the problem. When was the last time any Linux > distributions used an unmodified *released* GCC? Probably never. Andreas is talking about compatibility to a released version, he is not insisting on no patches. A few patches to solve localized problems (example: Debian's patched 2.95.2) is not an issue; no GNU/Linux distributor ships unmodified Linux kernels either, for similar reasons. It only becomes an issue when incompatibilities arise or changes don't get merged back in. These mini-forks are not a problem because everything keeps getting re-synced again. It's only an issue if things start growing apart or people can't resolve their differences. > None > of the *released* GCCs was good enough to build a whole Linux > distribution. Every vendor has to modify a *released* GCC or > take a snapshot from CVS. One way to solve it for Linux is to have > a vendor-natural Linux gcc, which is known to be able to compile > a complete, working Linux distribution. But given the release > schedule of gcc, unless a Linux distribution wants to sync their > release schedule with gcc, which I don't believe is likely to happen, > I don't think such a Linux gcc will be a *released* GCC. Given the circumstances in the last couple of years, this is understandable. Something like 2.95.3 should have come out ages before it did, but we weren't in a position to do releases at that time because we had no release manager. I'd like to get 3.0.x in shape to be usable for complete GNU/Linux distributions as soon as possible. > why I suggested making bug fix releases of gcc every 2 or 3 weeks > so that there is a chance that we can use a *released* GCC for > Linux distributions. Of course, I am assuming that those bug fix > releases fix the reported Linux build bugs. It's not necessary to do a whole lot of releases to make this happen: we have a 3.0 CVS branch. Volunteers who care about this can build from a CVS gcc (or download prebuilt releases from daily snapshots, like those CodeSourcery provides) and report failures. Our target for 3.0.1 is August 1. But it's not necessary to wait until that date to help find and fix problems. And remember that there will be lots of problems in apps as well as the compiler. Incorrect #ifdefs that break with the bump in major version number; invalid C++ code that happened to work with 2.95.x, etc.