Back to the Future - 64-bit time_t on sparc64
Garance A Drosihn
drosih at rpi.edu
Sat Feb 21 10:59:20 PST 2004
At 2:07 PM +0100 2/21/04, Harti Brandt wrote:
>GAD>I *think* what would work is something like:
>GAD>In /etc/make.conf, users would define:
>GAD>SPARCWORLD_TIMET=32bit or SPARCWORLD_TIMET=64bit
>GAD>If neither is defined, than 32-bit is assumed.
>That would look like an option to build either way and I think
>we shouldn't have such an option that allows 32bit time_t's.
>This will require to ship to sets of packages and will give as
>a lot of bug reports because of mismatched packages and kernels.
Well, I was just giving a basic idea of something we could do,
I did not mean to imply this is all we would ever do. This
would just be a transition aid, and like all transition aids
it would eventually disappear.
Initially, I think we DO want to allow 32-bit builds. But then,
after a week or two, we would simply change the script to say:
"I'm sorry dave,
but I can't let you do 32-bit builds anymore".
Why do we want to allow 32-bit builds?
Because the instructions say:
First do a 32-bit build. Install it.
Once you know that that installation is working,
Change _types.h, do a 64-bit build, and install that.
>GAD> I am certain that there are some details I have overlooked, but
>GAD> I really don't have the time to think it through right now.
I probably should have *started* my message by emphasizing this part
more strongly. I think the low-level details are workable, but some
developer would have to sit down and think them out. That is what I
do not have the time to do.
Also keep in mind that whatever we do for 5.x-current, we will
also have users who are sticking on 5.2.1-security until 5.2-
release comes out. It would be nice if they also had a way to
make a smooth transition, without the risk of shooting their
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-sparc64