http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> 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?
