time_t on sparc64 (it seems to work)
brandt at fokus.fraunhofer.de
Thu Oct 16 03:47:49 PDT 2003
On Wed, 15 Oct 2003, Garance A Drosihn wrote:
GAD>At 12:09 PM -0700 10/15/03, Marcel Moolenaar wrote:
GAD>>On Wed, Oct 15, 2003, Garance A Drosihn wrote:
GAD>>> I agree it would be better if we had 64-bit time_t's for
GAD>>> 5.x-STABLE. I would really really like to see that. However,
GAD>>> we are hoping to make 5.x turn into 5.x-stable with a release
GAD>>> of 5.2 in December.
GAD>>In fact, 5-stable happens no sooner than 5.3 in Feb 2004. Make
GAD>>the switch before 5.2 and you have enough time to deal with
GAD>>ports that suddenly start to break.
GAD>Oh. I thought it was going to be 5.2. Well, I'm still uneasy
GAD>about making the change, but I don't object quite as much if
GAD>we aren't shooting for -stable in 5.2.
Well, I tried to get a first impression on how hard this change would be.
I have a ultra-10 to play with.
The only thing I did (after a couple of greps in sys/sparc64) was to
change __time_t to __int64_t. I then recompiled everything and installed
the new kernel. Just for fun I booted the kernel and - hey - it works. It
comes even in multiuser mode, albeit without NFS file systems. I then
rebooted the old kernel and did a make installworld. I expected this to
fail at some place, because it would use the new tools (which expect 64bit
time_t from the kernel) on the old kernel. It goes quite far - the
stopper is zic which enters an endless loop. I stopped the install and
rebooted the new kernel into single user, mounted my NFS file systems
(my src and obj are on a server) by hand and tried the make install
again. This time it stopped in include, probably because it was now using
the old make which couldn't correctly resolve the file times anymore. I
installed the new make handish and tried the installworld again. This time
it stopped in sendmail, because the old find doesn't work as expected.
Installing the new find did the trick. After a mergemaster and a reboot
everything seems to be just fine.
Of course you need to recompile all ports (unless you know which port
won't used stat() or gettimeofday().
So given that things are quite simple I would argue to do the move now,
before the sparc port will really be used as -stable in production
systems. With a little help from the build infrastructure people it may be
possible to ensure that the above will work more automatically. Also the
sparc gurus should probably have a look at the MD parts, whether there is
something that needs to be changed.
So when will we do it?
brandt at fokus.fraunhofer.de, harti at freebsd.org
More information about the freebsd-sparc64