Gearing up for 64-bit time_t on sparc64

[Garance A Drosihn]

At 9:43 AM -0800 1/7/04, David O'Brien wrote:
>On Wed, Jan 07, 2004 at 12:08:13AM -0500, Garance A Drosihn wrote:
>>  How flexible should we be?  My first thought is to tell people:
>>
>>     1) upgrade to RELENG_5_2
>>     2) *after* you know that upgrade worked, then run a patch
>>        file (which will already be in /usr/src?), which will
>>        modify the appropriate files needed for this change.
>>     3) rebuild after making just that one change.  No cvsup.
>
>I think it has to all be doable given a CVS archive, no
>external patches.

That is certainly less work for me to do, but..

>  > Or we could do a more flexible version, combining a -Define in
>>  CFLAGS (set in /etc/make.conf), along with some extra magic
>>  when installing the include files during 'make installworld'.
>>  Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64.
>
>I think we should only do this if we can't achieve this as above.

part of the reason for doing this is to allow more people to
help me test whatever procedure I dream up.  It takes me more
than seven hours to do buildworld+buildkernel+installkernel,
and more to finish up any given test. And at the end of that,
all we know is that it works for me on my Ultra 10.

So, there would be some benefit if I had something that could be
committed without changing anything for anyone, and then we could
pull in a few more people to test it by flipping the switch
in /etc/make.conf.

However, my first attempt at doing that shows that it isn't as
simple to do as I'd like.  Some things in buildworld are compiled
without CFLAGS from /etc/make.conf, and it would probably waste
too much time to figure out fixes for those.

I have another 64-bit build going right now, but I'll have to
wait until tomorrow to see how it works out.

-- 
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