Message ID | 20120824094738.GH29273@rox.home.comstyle.com |
---|---|
State | New |
Headers | show |
On 24 August 2012 10:47, Brad Smith <brad@comstyle.com> wrote: > OpenBSD's uname works as expected with the -s flag so remove the special > handling when determining the target OS. Use arch -s to retrieve the > hardware architecture as uname -m will return the meta architecture > instead of the hardware architecture (.e.g. macppc vs powerpc). I'm afraid I think this patch is moving in the wrong direction. Wherever possible we should be using compiler checks like check_define, not looking at the output of 'uname' and the like. The former will work when cross compiling, and the latter will give the wrong answers. In some places we have that kind of 'look at uname/etc' check but we should be trying to reduce and eliminate it where possible. thanks -- PMM
On Fri, Aug 24, 2012 at 10:55:10AM +0100, Peter Maydell wrote: > On 24 August 2012 10:47, Brad Smith <brad@comstyle.com> wrote: > > OpenBSD's uname works as expected with the -s flag so remove the special > > handling when determining the target OS. Use arch -s to retrieve the > > hardware architecture as uname -m will return the meta architecture > > instead of the hardware architecture (.e.g. macppc vs powerpc). > > I'm afraid I think this patch is moving in the wrong direction. > Wherever possible we should be using compiler checks like check_define, > not looking at the output of 'uname' and the like. The former will > work when cross compiling, and the latter will give the wrong answers. > In some places we have that kind of 'look at uname/etc' check but > we should be trying to reduce and eliminate it where possible. Ah, ok. I thought maybe it could be simplified in favor of using uname more so. That's fine with me. I'll drop it.
Il 24/08/2012 11:55, Peter Maydell ha scritto: >> > OpenBSD's uname works as expected with the -s flag so remove the special >> > handling when determining the target OS. Use arch -s to retrieve the >> > hardware architecture as uname -m will return the meta architecture >> > instead of the hardware architecture (.e.g. macppc vs powerpc). > I'm afraid I think this patch is moving in the wrong direction. > Wherever possible we should be using compiler checks like check_define, > not looking at the output of 'uname' and the like. The former will > work when cross compiling, and the latter will give the wrong answers. > In some places we have that kind of 'look at uname/etc' check but > we should be trying to reduce and eliminate it where possible. Right, we should support GNU triplets and a --host argument, and replace uname checks with pattern matching on the triplet. Paolo
On Fri, Aug 24, 2012 at 01:56:31PM +0200, Paolo Bonzini wrote: > Il 24/08/2012 11:55, Peter Maydell ha scritto: > >> > OpenBSD's uname works as expected with the -s flag so remove the special > >> > handling when determining the target OS. Use arch -s to retrieve the > >> > hardware architecture as uname -m will return the meta architecture > >> > instead of the hardware architecture (.e.g. macppc vs powerpc). > > I'm afraid I think this patch is moving in the wrong direction. > > Wherever possible we should be using compiler checks like check_define, > > not looking at the output of 'uname' and the like. The former will > > work when cross compiling, and the latter will give the wrong answers. > > In some places we have that kind of 'look at uname/etc' check but > > we should be trying to reduce and eliminate it where possible. > > Right, we should support GNU triplets and a --host argument, and replace > uname checks with pattern matching on the triplet. That still requires a means of generating that triplet in the first place.
Il 24/08/2012 14:00, Brad Smith ha scritto: >>>>> > >> > OpenBSD's uname works as expected with the -s flag so remove the special >>>>> > >> > handling when determining the target OS. Use arch -s to retrieve the >>>>> > >> > hardware architecture as uname -m will return the meta architecture >>>>> > >> > instead of the hardware architecture (.e.g. macppc vs powerpc). >>> > > I'm afraid I think this patch is moving in the wrong direction. >>> > > Wherever possible we should be using compiler checks like check_define, >>> > > not looking at the output of 'uname' and the like. The former will >>> > > work when cross compiling, and the latter will give the wrong answers. >>> > > In some places we have that kind of 'look at uname/etc' check but >>> > > we should be trying to reduce and eliminate it where possible. >> > >> > Right, we should support GNU triplets and a --host argument, and replace >> > uname checks with pattern matching on the triplet. > That still requires a means of generating that triplet in the first place. That's what GNU config.guess is for, but it is only used in the non-cross-compilation case. QEMU's homegrown configure hardly distinguishes between native and cross builds. Paolo
On Fri, Aug 24, 2012 at 02:02:57PM +0200, Paolo Bonzini wrote: > Il 24/08/2012 14:00, Brad Smith ha scritto: > >>>>> > >> > OpenBSD's uname works as expected with the -s flag so remove the special > >>>>> > >> > handling when determining the target OS. Use arch -s to retrieve the > >>>>> > >> > hardware architecture as uname -m will return the meta architecture > >>>>> > >> > instead of the hardware architecture (.e.g. macppc vs powerpc). > >>> > > I'm afraid I think this patch is moving in the wrong direction. > >>> > > Wherever possible we should be using compiler checks like check_define, > >>> > > not looking at the output of 'uname' and the like. The former will > >>> > > work when cross compiling, and the latter will give the wrong answers. > >>> > > In some places we have that kind of 'look at uname/etc' check but > >>> > > we should be trying to reduce and eliminate it where possible. > >> > > >> > Right, we should support GNU triplets and a --host argument, and replace > >> > uname checks with pattern matching on the triplet. > > That still requires a means of generating that triplet in the first place. > > That's what GNU config.guess is for, but it is only used in the > non-cross-compilation case. QEMU's homegrown configure hardly > distinguishes between native and cross builds. OK well if you're going in that direction that's fine as config.guess knows how to do the right thing.
diff --git a/configure b/configure index d97fd81..6073dd2 100755 --- a/configure +++ b/configure @@ -303,8 +303,6 @@ if check_define __linux__ ; then targetos="Linux" elif check_define _WIN32 ; then targetos='MINGW32' -elif check_define __OpenBSD__ ; then - targetos='OpenBSD' elif check_define __sun__ ; then targetos='SunOS' elif check_define __HAIKU__ ; then @@ -332,6 +330,11 @@ SunOS) if test -z "$cpu" && test "$(isainfo -k)" = "amd64"; then cpu="x86_64" fi + ;; +OpenBSD) + # 'uname -m' returns the meta arch macppc instead of the hw arch powerpc + cpu=`arch -s` + ;; esac if test ! -z "$cpu" ; then
OpenBSD's uname works as expected with the -s flag so remove the special handling when determining the target OS. Use arch -s to retrieve the hardware architecture as uname -m will return the meta architecture instead of the hardware architecture (.e.g. macppc vs powerpc). Signed-off-by: Brad Smith <brad@comstyle.com>