From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 9 00:09:12 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344B416A4CE for ; Fri, 9 Jan 2004 00:09:12 -0800 (PST) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63BDF43D53 for ; Fri, 9 Jan 2004 00:09:09 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.12.8/8.12.8) with ESMTP id i09896Kx015796 for ; Fri, 9 Jan 2004 03:09:06 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040107174346.GA50142@dragon.nuxi.com> References: <200312212239.38557.craig@xfoil.gank.org> <20040106095942.O66232@beagle.fokus.fraunhofer.de> <20040106182824.GA42422@dragon.nuxi.com> <20040107174346.GA50142@dragon.nuxi.com> Date: Fri, 9 Jan 2004 03:09:04 -0500 To: freebsd-sparc64@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Gearing up for 64-bit time_t on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 08:09:12 -0000 At 9:43 AM -0800 1/7/04, David O'Brien wrote: >On Wed, Jan 07, 2004 at 12:08:13AM -0500, Garance A Drosihn wrote: >> How flexible should we be? My first thought is to tell people: >> >> 1) upgrade to RELENG_5_2 >> 2) *after* you know that upgrade worked, then run a patch >> file (which will already be in /usr/src?), which will >> modify the appropriate files needed for this change. >> 3) rebuild after making just that one change. No cvsup. > >I think it has to all be doable given a CVS archive, no >external patches. That is certainly less work for me to do, but.. > > Or we could do a more flexible version, combining a -Define in >> CFLAGS (set in /etc/make.conf), along with some extra magic >> when installing the include files during 'make installworld'. >> Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64. > >I think we should only do this if we can't achieve this as above. part of the reason for doing this is to allow more people to help me test whatever procedure I dream up. It takes me more than seven hours to do buildworld+buildkernel+installkernel, and more to finish up any given test. And at the end of that, all we know is that it works for me on my Ultra 10. So, there would be some benefit if I had something that could be committed without changing anything for anyone, and then we could pull in a few more people to test it by flipping the switch in /etc/make.conf. However, my first attempt at doing that shows that it isn't as simple to do as I'd like. Some things in buildworld are compiled without CFLAGS from /etc/make.conf, and it would probably waste too much time to figure out fixes for those. I have another 64-bit build going right now, but I'll have to wait until tomorrow to see how it works out. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu