64-bit time_t on sparc64, epilogue(?)
brandt at fokus.fraunhofer.de
Sat Nov 15 07:06:42 PST 2003
On Sat, 15 Nov 2003, Garance A Drosihn wrote:
GAD>At 11:35 PM -0700 11/14/03, Scott Long wrote:
GAD>>Garance A Drosihn wrote:
GAD>>>Recently on the freebsd-sparc64 list, it was mentioned
GAD>>>that it would be nice to upgrade time_t on that port to
GAD> [...mumble mumble...]
GAD>>>So, I thought I'd explicitly say that I don't think we
GAD>>>should make the change this late in the game..
GAD>>Switching to 64-bit time_t this late in the 5.2 cycle will
GAD>>likely cause more excitement than we can handle. ...
GAD>>...Why don't we put this on the TODO list for 5.3, and
GAD>>plan to do it in early January, assuming that Jake and
GAD>>Thomas are ok with it.
GAD>Personally I am inclined to think that we have to stop
GAD>making ABI/API changes to 5.x or we will never ever get
GAD>to "5.x-stable". It would be nice if 5.2 were the last
GAD>set of API/ABI changes, so that people who install it can
GAD>at least have a painless upgrade to 5.3-release (which
GAD>will hopefully be 5.x-stable).
GAD>However, I really would like to see the 64-bit time_t
GAD>happen, and I'm certainly willing to help out (as time
GAD>permits) if we were to make this change on sparc64 in
GAD>early January. I'll even start testing such changes on
GAD>my own sparc64 system during the code-freeze for 5.2.
GAD>[however, it takes about 11 hours for build/installworld
GAD>on my system, so there's a limit to how much I can test!]
GAD>Certainly it's more important to get make-release and
GAD>kse-for-sparc64 working for 5.2-release than it is to
GAD>make this time_t change.
I'm running one of my two sparcs since then without any problem with
64-bit time_t (I don't have many ports on it - perl, bash, a dozen or so).
I was waiting for thomas and jake to say something on this. Also someone
wanted to test it, but I did not here from him. I think that Scott is
right, it's too late for 5.2 but we should definitely try to do it for
5.3. The biggest problem is getting the upgrade process right, but this
should be manageable.
brandt at fokus.fraunhofer.de, harti at freebsd.org
More information about the freebsd-arch