time_t on sparc64 (it seems to work)
Garance A Drosihn
drosih at rpi.edu
Fri Oct 17 12:27:59 PDT 2003
At 12:47 PM +0200 10/16/03, Harti Brandt wrote:
>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. ...
>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.
>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.
I would say that your own description falls a little short of
being "quite simple"...
>Of course you need to recompile all ports (unless you know
>which port won't used stat() or gettimeofday().
Which is even more work that every-sparc64-user would have to
do. It also means that there is a lot that you have not really
tested with the above. It also means that any pkg-building
will have provide packages for both 64-bit and 32-bit time_t
systems, unless you can somehow get everyone to rebuild their
systems on the same day.
>With a little help from the build infrastructure people it
>may be possible to ensure that the above will work more
But that is also "more work" for some developers would have to
do, and they'd have to do it "right now".
>So when will we do it?
I definitely do like the idea of getting to 64-bit time_t on
sparc64 before 5.2-release, but there is no question that it
adds to the work necessary before "5.x" becomes "5.x-stable".
If we are going to do it, we should talk as if we are going
to do it "Right Now", or we should admit that it must wait
until 6.0-current. I am willing to go through the same steps
that you went through to get my one (1) sparc64 system to be
running with 64-bit timestamps. I'm willing to recompile all
the ports on mine. However, I don't really use my sparc64
system for all that much, and I can afford to erase the disk
and start over if this really botches things up. And even
if everything that I do works fine, that won't be much of a
test. There is a lot of stuff that I do NOT do which someone
would be doing if they used a sparc64 system as their primary
So I am willing to try to do a 64-bit time_t on my one system,
but only if there is a list of others who are going to do the
same thing. We're only going to get from "here" to "there" if
we start working on it, and we must see multiple developers
stepping up Right Now who are willing to do that work (even if
it's just testing-work, it has to be done).
Otherwise, let's concentrate on getting to 5.x-stable, and put
off all talk of 64-bit time_t's until we create 6.0-current.
Garance Alistair Drosehn = gad at gilead.netel.rpi.edu
Senior Systems Programmer or gad at freebsd.org
Rensselaer Polytechnic Institute or drosih at rpi.edu
More information about the freebsd-standards