Date: Wed, 17 Mar 2004 13:55:14 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: obrien@freebsd.org Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: 64-bit time_t package build starting Message-ID: <p06020415bc7e49f18cb0@[128.113.24.47]> In-Reply-To: <20040317180453.GD94853@dragon.nuxi.com> References: <20040317000232.GA52319@xor.obsecurity.org> <p06020411bc7d63d99ec9@[128.113.24.47]> <20040317180453.GD94853@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:04 AM -0800 3/17/04, David O'Brien wrote: >On Tue, Mar 16, 2004, Garance A Drosihn wrote: > > At 4:02 PM -0800 3/16/04, Kris Kennaway wrote: > > >One of the sparc package machines deadlocked, so while rebuilding > > >it I decided to update the machines to -CURRENT instead. ... > > >> Is there a schedule for getting some fix into the ezm3 port, >> such as: >> http://people.freebsd.org/~gad/time-64/port-ezm3.diff > >Why can't we just use __FreeBSD_version and avoid the extra >stuff in the port? a) the way modula-3 works, there is no __FreeBSD_version that the modula-3 source code can easily check. Maybe there should be, but this was an easier update for me to write. b) this update was written before the 64-bTT change was committed, because people needed it for testing the 64-bTT change. As such, I needed something which would work correctly before __FreeBSD_version had been updated. (and indeed, we didn't even know what the correct version# would be). c) (less significant) It may be that some users will want to update their 5.2.1 system to 64-bTT before they jump to 5.3-release. If I had a 5.2.1 system, that is how I would do the jump to 5.3-release (once it is available). However, I have no strong opinion on how the fix should be done. All I felt responsible for was coming up with *some* fix which could be used to prove that cvsup could be made to work after the 64-bTT transition. The update I provided does work, and it should work reliably for everyone (both 32-BTT and 64-bTT), but I have no objection at all to any alternate fix that anyone else wants to come up with. I just wrote up the first thing that came to mind, and that I was pretty confident would work for everyone. What I added was basically a tiny compile-time auto-configure step for setting up time_t. Seemed like a clever idea at the time... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020415bc7e49f18cb0>