Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2011 08:47:24 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Doug Barton <dougb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r217213 - head/lib/bind
Message-ID:  <201101110847.24284.jhb@freebsd.org>
In-Reply-To: <4D2BE4F8.3030902@FreeBSD.org>
References:  <201101092347.p09NlB4M060802@svn.freebsd.org> <201101101433.18847.jhb@freebsd.org> <4D2BE4F8.3030902@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, January 11, 2011 12:04:56 am Doug Barton wrote:
> On 01/10/2011 11:33, John Baldwin wrote:
> > On Sunday, January 09, 2011 6:47:11 pm Doug Barton wrote:
> 
> >>   # Use the right version of the atomic.h file from lib/isc
> >> -ISC_ATOMIC_ARCH=${MACHINE_CPUARCH:S/i386/x86_32/:S/amd64/x86_32/}
> >> +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
> >
> > This should use MACHINE_CPUARCH instead of MACHINE_ARCH?
> 
> When this block was first written I don't think _CPUARCH existed at all, 
> and/or had not been MFC'ed. Subsequently, nwhitehorn made the change in 
> r209886 to use _CPUARCH in both places, however the diff from Warner's 
> commit in r217071 (which is what I based my change on) clearly showed 
> _ARCH 
> 
(http://svn.freebsd.org/viewvc/base/head/lib/bind/config.mk?r1=209886&r2=217071). 
> So, I'm not sure where svn went sideways there, but it's definitely "odd."

Huh?  Warner's change only used MACHINE_CPUARCH:

ISC_ATOMIC_ARCH=${MACHINE_CPUARCH:S/i386/x86_32/:S/amd64/x86_32/}

Nowhere in that line is MACHINE_ARCH used.  Only MACHINE_CPUARCH is used.

> I have no objection to putting it back to the state that it was in at 
> r209886, although frankly less diffs to RELENG_[78] without good reason 
> make my life easier.

209886 did not use MACHINE_CPUARCH for ISC_ATOMIC_ARCH, and in fact the file
is now back to the 209886 state (nwhitehorn did not change ISC_ATOMIC_ARCH
to use MACHINE_CPUARCH).

Fixing this does create diffs to [78] because MACHINE_CPUARCH is not present 
at all in [78], but that is because [78]'s handling of different endians for 
mips, arm, etc. is deficient.  You are likely stuck with using MACHINE_CPUARCH 
for 9+ and MACHINE_ARCH for <= 8.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101110847.24284.jhb>