From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10882 invoked by alias); 13 Apr 2004 18:44:07 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10872 invoked by alias); 13 Apr 2004 18:44:06 -0000 Date: Tue, 13 Apr 2004 19:48:00 -0000 Message-ID: <20040413184406.10869.qmail@sources.redhat.com> From: "ian at wasabisystems dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040303083528.14400.schmid@snake.iap.physik.tu-darmstadt.de> References: <20040303083528.14400.schmid@snake.iap.physik.tu-darmstadt.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug pch/14400] Cannot compile qt-x11-free-3.3.0 X-Bugzilla-Reason: CC X-SW-Source: 2004-04/txt/msg01096.txt.bz2 List-Id: ------- Additional Comments From ian at wasabisystems dot com 2004-04-13 18:44 ------- Subject: Re: Cannot compile qt-x11-free-3.3.0 "geoffk at gcc dot gnu dot org" writes: > So, the appropriate fix for *this* bug is to backport RTH's change to the 3.4 branch? I think we have some sort of mutual misunderstanding as to what this PR represents. If we interpret this PR as being specific to i686-pc-linux-gnu, then, yes, backporting RTH's changes would fix it. However, this bug exists because one of the gcc 3.4 release criteria was that gcc 3.4 be able to compile QT, as described here: http://gcc.gnu.org/gcc-3.4/criteria.html Personally, I would interpret that as meaning that QT should build on each relevant primary evaluation platform, which includes i386-unknown-freebsd among other non-GNU/Linux systems. This PR was filed because of a test of the release criteria, not because of a specific GNU/Linux issue. See the initial report in the PR. Backporting RTH's fix would be a good idea. And it would fix this PR as narrowly construed. But it would not fix the idea behind this PR, which is that QT compile with gcc 3.4 on all relevant systems. That's why I haven't pushed to backport RTH's fix: because the PR, in the general case, isn't fixed in mainline, either. I think that fixing it properly in mainline is a prerequisite to fixing it in 3.4. Ian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14400