switch to 64-bit time_t on x86_64

[korli]

This implies a binary compatibility break.

Affected headers: headers/posix/time.h

The use of these functions should be reviewed: it becomes problematic when they are used with time_t arguments.

extern uint32		real_time_clock(void);
extern void		set_real_time_clock(uint32 secsSinceJan1st1970);

[pulkomandy]

Should we do this before beta1? Delaying it until R2 seems a bit risky given our development speed and how close the end of 32bit UNIX timestamps is…

[waddlesplash]

I say we do it as soon as we have the package buildbots ready.

[kallisti5]

Since we have to rebuild all packages for the release, and the actual change is pretty simple, lets try to finish this one before R1.

I assume we could do something like this?

• gcc2 uint32 (To keep BeOS Compat)
• everything else(tm) time_t ?

[korli]

Is that so simple? Once the change is made, a few packages won't work correctly anymore, of these seem several critical to rebuild the rest.

[kallisti5]

Do we have any knowledge of which packages? We're not going to know until someone tries it :-)

[pulkomandy]

I was thinking about swithing everything but gcc2, but I don't know if time_t is used in any syscalls or BMessages. If it is the case, we would hit some interesting problems on hybrids, if time_t is not the same for the two compilers.

And yes, once the change is made, our existing package set may not be able to boot Haiku anymore because of mismatched time_t. Which would mean we need to bootstrap or at least rebuild some packages from haikuports_cross again to get things booting again. And only then we can rebuild the other affected packages.

[waddlesplash]

Done in hrev51198. Turns out a bootstrap wasn't needed.

[korli]

waddlesplash, sorry to ask, but how do we follow up on this? I suspect a lot of hpkgs are now broken, from which some are required to build. At least please issue a warning on the mailing list against updating to this hrev.

[waddlesplash]

I suspect a lot of hpkgs are now broken, from which some are required to build.

Actually it appears not a whole lot of stuff is broken. WebPositive, for instance, still works, but OpenSSL probably needs to be recompiled as it gives "expired certificate" errors and other strange things related to date validation and the like.

If the new package build server is ready for people to use it, then this is the perfect way to test that, actually. But I haven't heard much from PulkoMandy on that lately...

[kallisti5]

Good thing I have 3 nodes now dedicated to building x86_64 packages :-)