From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvdpu-00087V-5b for qemu-devel@nongnu.org; Thu, 09 Feb 2012 18:55:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rvdpt-0004T6-3s for qemu-devel@nongnu.org; Thu, 09 Feb 2012 18:55:34 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:60873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvdps-0004T0-NE for qemu-devel@nongnu.org; Thu, 09 Feb 2012 18:55:32 -0500 From: Paul Brook Date: Thu, 9 Feb 2012 23:55:26 +0000 References: <20120209163708.21062.43255.malonedeb@chaenomeles.canonical.com> <201202091918.26231.paul@codesourcery.com> <8617E9F5-7049-45FD-BD35-1C121EAB91FC@suse.de> In-Reply-To: <8617E9F5-7049-45FD-BD35-1C121EAB91FC@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202092355.27165.paul@codesourcery.com> Subject: Re: [Qemu-devel] [Bug 929638] Re: qemu 1.0 unable to compile on the pandaboard ES List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , qemu-devel@nongnu.org, Andreas =?iso-8859-1?q?F=E4rber?= > > I'd rather not. If at all possible we should avoid runtime tests. Even > > for "native" systems they generally give the wrong answer as the machine > > you're building on often isn't the one you will be running on. If we > > know arm hosts are broken then that's what we should test for in > > configure (with a comment saying why). > > > > IMO consistency between builds for the same target environment is more > > important than opportunistically probing in a native builds. > > I agree for CPU features, sure. Anything that would be influenced by your > build system vs execution environment. But in this case we're probing for > a feature of a library we're linking against, so runtime checks really > aren't all that bad, since you usually want to build against the same libc > that you're executing against later on. Maybe, but I don't consider "assume it's broken when cross compiling" to be an acceptable answer. If we can't get the same answer in a cross environment then I don't want to be doing it at all. Using a native build environment is often infeasible. The Debian/Ubuntu and Maemo folks do crazy things to make it happen, but often as not you're cross building the whole system from scratch. Even in a desktop context, all my production builds are done with a cross compiler[1]. Having that cross build behave differently from a native build using the exact same libraries and config is liable to cause the absolute worst kind of bugs - the sort that only shows up in something you're about to/already have shipped to the customer. Paul [1] The build cluster runs modern 64-bit linux, but the end result needs to work on older 32-bit linux and windows. There's no way I'm setting up a cluster of RHEL4 and windows XP machines to do native builds, but I can easily maintain a cross toolchain to win32 or RHEL4 i686 sysroot indefinitely.