Date: Tue, 24 Feb 2004 23:05:16 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: John Polstra <jdp@polstra.com>, Ken Smith <kensmith@cse.Buffalo.EDU> Cc: freebsd-sparc64@freebsd.org Subject: RE: 64btt cvsup? Message-ID: <p06020487bc61aea919fe@[128.113.24.47]> In-Reply-To: <XFMail.20040224164527.jdp@polstra.com> References: <XFMail.20040224164527.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:45 PM -0800 2/24/04, John Polstra wrote: >On 20-Feb-2004 Ken Smith wrote: > > Has anyone tried using cvsup on a 64btt system yet? I'm getting > > odd results on a system being set up as a cvsup mirror - it seems > > to think it needs to touch (timestamp correction) every file in > > the repo but there is no visible change to the timestamp on the > > files themselves. > >Well, Modula-3 still thinks time_t is 32 bits, of course. I haven't >looked at the patches for a 64-bit time_t, so I'm not sure what >provisions have been made for backward compatibility. None. We change the type for __time_t, and recompile everything. This puts us in the same camp as the amd64 and ia64 ports. We pretend that the sparc platform never had a 32-bit time_t. >I assume you (the collective "you") kept compatibility versions >of time(2), stat(2), lstat(2), etc., with 32-bit time_t fields >so that existing executables would continue to work. No. >However, if you rebuild CVSup from source, it will most likely >have problems. This will be the case until I or somebody else >adds a few patches to the port to deal with the change. In my testing, I did a force-rebuild of cvsup-without-gui and the ezm3 ports (after the upgrade). As near as I can tell, cvsup has been working OK for me since then. I must admit that I have only >If __FreeBSD_version wasn't already bumped to mark the change to >a 64-bit time_t, somebody please bump it ASAP. We're going to >need that in order to know whether to apply the new patches or not. The change has not been committed yet. However, this *is* a detail that I had overlooked. Indeed, we probably should change __FreeBSD_version. As mentioned recently in HEADSUP to -hackers, -arch, and -current, I intend to make an initial set of commits on March 3rd, and then commit "the real change" on March 10th. [Oops, I gotta go right now... I'll finish this reply in a later message] -- 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?p06020487bc61aea919fe>