From owner-freebsd-amd64@FreeBSD.ORG Sat Jan 31 21:49:08 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EA3116A4CE for ; Sat, 31 Jan 2004 21:49:08 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03D2743D1D for ; Sat, 31 Jan 2004 21:49:05 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.10/8.12.9) with ESMTP id i115mxA0058810; Sat, 31 Jan 2004 21:48:59 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.10/8.12.10/Submit) id i115mu0s058809; Sat, 31 Jan 2004 21:48:56 -0800 (PST) (envelope-from obrien) Date: Sat, 31 Jan 2004 21:48:56 -0800 From: "David O'Brien" To: Bill Squire Message-ID: <20040201054856.GB58573@dragon.nuxi.com> References: <1075530947.840.2.camel@.rochester.rr.com> <20040131074830.GA18624@dragon.nuxi.com> <1075535725.1189.4.camel@.rochester.rr.com> <20040131080038.GE18624@dragon.nuxi.com> <20040131193105.GA21759@curacao.n2it.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040131193105.GA21759@curacao.n2it.nl> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-amd64@freebsd.org Subject: Re: XFree86 build X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 05:49:08 -0000 On Sat, Jan 31, 2004 at 08:31:05PM +0100, Bill Squire wrote: > On Sat, Jan 31, 2004 at 12:00:38AM -0800, David O'Brien wrote: > > On Sat, Jan 31, 2004 at 02:55:25AM -0500, Jem Matzan wrote: > > > On Sat, 2004-01-31 at 02:48, David O'Brien wrote: > > > > On Sat, Jan 31, 2004 at 01:35:47AM -0500, Jem Matzan wrote: > > > > > What's in your /etc/make.conf? I have CPUTYPE?=?x86_64 for the CPU > > > > > type, > > > > > > > > That is so totally wrong, I don't know where the idea could have come > > > > from. There is a single AMD64 implimentation at this time, so there are > > > > no choices (or things to tweak). x86_64 is Linux's bastardized spelling > > > > of "AMD64". > > > > > > Hey that's wonderful, but do you have a suggestion as to what the > > > CPUTYPE should be? > > > > Yes, don't set it. > > Here is a question for David or anybody: > > CPUTYPE?=. is therefore correct? (or nothing at all?) That is still setting it -- to ".". Don't set it, don't have it anywhere, a grep of CPUTYPE of /etc/make.conf should show nothing. There is no need for it -- please think about what CPUTYPE is for? It isn't to tell the compiler on your Alpha system you want to generate sparc64 code. It is to tell the compiler which generation of a family you have, and what member of a CPU family to opimize for. There is a single AMD64 cpu so far -- K8. Since there is but one, there is nothing to tell the compiler -- it already knows everything there is to know. > The two settings below have worked well for some time now. Is this wrong > too? > > CPUTYPE?= amd64 > TARGET_ARCH?= amd64 Don't set TARGET_ARCH unless you are doing a cross-build. > Is there any chance of setting compatibility for "Linux's bastardized > spelling" of 'amd64' at the top level? (In /etc/make.conf ?) No, I personally will kill any proliferation of that bastardized spelling. > This is still one (if not the most) common trivial patch in the ports. Please show explicity where you are needing to specify it. With Kris and Co.'s /usr/ports/Templates the need should be minimal. > Placing -fPIC in CFLAGS= sometimes causes the compiler to bomb, while not > having it to make some some libs (in the right Makefile) will cause the > linker to bomb with a very Linux like "x86_64_32" in the error message. SPECIFICS please. It sounds like you are talking about relocations, but we need the specific details. > What gives? It certainly is "amd64", but "HAMMER" is still used to ID the > "amd64" in the kernel conf? Certainly I like what I have, but if there is > one and only one "amd64", calling it by atleast three names looks like > trouble. Hammer is the internal AMD code name for AMD64, it existed years before the term "AMD64" did. In GENERIC it tells the CPU family member. Maybe we should change it, but many of us like it. The kernel has place holders for future CPU families, like K9 and K10.