Gearing up for 64-bit time_t on sparc64

Garance A Drosihn drosih at
Fri Jan 9 23:21:06 PST 2004

After reading over what Harti had done, and staring at the
standard makefiles awhile, I ended up writing one helper-
script.  With this helper-script, the upgrade to 64-bits
went fairly smooth.

For my switch, what I did was:
      cvsup to -current
      update & install that snapshot (using the standard
               updating procedures, this is still the
               32-bit time_t system)

    1) change __time_t to __int64_t
    2)  rm -Rf /usr/obj/usr/src/*
    3)  make buildworld && make buildkernel && make installkernel
        (wait seven hours...)
    4)  mergemaster -p             <- not really needed...
    5)  reboot into single-user mode.
    6)  cd /usr/src                <- or NFS-mounted equivalent
    7)  installworld_nk            <- magic script
    8)  mergemaster                <- not really needed...
    9)  Reboot, and come up on complete
                new 64-bit time_t system.
   10)  portupgrade -Rr -f ruby portupgrade
   11)  portupgrade -Rr -f bash python
   12)  --->    Have To Do Something with CVSUP   <---
        (in my case, I'll probably rebuild all of ezm3
        and cvsup, but I doubt that everyone would want
        to do that.  We probably need to have a pre-built
        64-bit cvsup available as pkg or a download)
   13)  portupgrade other ports...

Doing it this way, I hit no snags.  Or at least, I haven't
noticed any yet.  This could be made even easier by
collapsing the 'installworld_nk' script into some new
'installworld_nk' target in /usr/src/Makefile.  The script
tries to be as general a solution as possible -- it is not
specific to this 64-bit time_t change.

("nk" is short for "New Kernel")

1)  Since I only change this one single line, there really is
     no need for doing things like mergemaster.  I really like
     the idea that when switching to 64-bit time_t, that should
     be the *only* change you're making from a system that you
     already know is working on your hardware.

4)  If one would do 'mergemaster -p', it would probably be
     best do to it before shutting down, instead of after
     booting into a 64-bit kernel and 32-bit world.

5)  Usually I cheat on this, and I reboot into multi-user
     mode and then 'shutdown now' to get into single-user mode.
     That cheat does not work well when making this change.
     You really have to 'boot -s', pick your shell, and do a
     'mount -a'.  Probably should start swap too, but I have
     enough ram that I don't have to care about that part.
5a) For the general case, this is the "shakey-ist" step,
     because I started up on a /bin/sh which was not built
     for the new kernel.  For this specific change, that did
     not seem to be a problem.

6)  The way I wrote the script, I expect it would work for
     people who do installs via NFS-mounted filesystems,
     perhaps mounted at somewhere other than /usr/src.
     However, I am not setup to test that.  I am testing
     only the standard case of /usr/src and /usr/obj.

7)  What the standard 'make installworld' does, is it looks for
     a list of programs, does a 'which $prog' on them, and copies
     all of those (from the "old system") into a temp directory,
     and changes PATH to use that directory.

     What my script does is take that same list of programs,
     copies them out of ${.OBJDIR} into a temp directory,
     changes PATH to add on the new directory, removes one
     PATH= command from a copy of /usr/src/Makefile, and then
     runs the standard 'installworld' target.  So, using this
     tactic it should be true that *every* program needed by
     the installworld process will match the new kernel.  I
     know that doesn't happen for /bin/sh, and I can't prove
     that it did happen for all other programs, but I did get
     through the entire installworld without error-ing out.

     That's why I say this could be collapsed into a new standard
     target.  The script is only doing a slight variation from
     the standard installworld target.  I am not going to *do*
     that, I'm just saying it could be done.

10) I use portupgrade to update ports, so I figured this
     was the obvious first-step.  After that, I've just been
     upgrading ports which "I expect" need to be upgraded.

After that, I did the dumb test of:

irb       <- interactive ruby
test =
test += 3600*24*365

and kept repeating the last command.  On a 32-bit time_t, the
command errors out in 2038.  On the new system, it just keeps
going up.

I hope to do a repeat test of all of this work sometime over
the weekend.  I also might try to make some more improvements.

Garance Alistair Drosehn            =   gad at
Senior Systems Programmer           or  gad at
Rensselaer Polytechnic Institute    or  drosih at

More information about the freebsd-sparc64 mailing list