From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1334 invoked by alias); 11 Jan 2011 08:37:01 -0000 Received: (qmail 1322 invoked by uid 22791); 11 Jan 2011 08:37:00 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BJ,TW_CX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Jan 2011 08:36:55 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: objc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 11 Jan 2011 09:33:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg01004.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488 --- Comment #13 from Iain Sandoe 2011-01-11 08:36:42 UTC --- (In reply to comment #12) > (In reply to comment #11) > > should this be closed as fixed - and, if not, what is the remaining issue? > > The remaining issue is that the just built compiler under test looks in > the install location. I.e. bogus files from a previous borched install could > cause failures, or a missing file in the build could be masked by having the > file in the install location. OK, that is agreed, but AFAIK, it applies to GCC (or the test-suite) as a whole. (I'm sure every dev. has at some stage been burnt by a pre-existing install). It's also an issue when one wants to build version X.Y.Z to sit in the same place as version P.Q.R. (--enable-version-specific-runtime-libs is a great option :) ). Here, I always: (a) do uninstalled testing (b) use a different (and unpopulated) install location from the final one when testing. (after all, one tends to debug with --enable-checking=yes and build the final with --enable-checking=release). --- So, unless I'm missing some finer point of your comment, this is not an ObjC-specific problem -- perhaps a new PR could be raised for an enhancement to greater robustness of the test-suite in the presence of installed programs?