Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#11124 closed bug (fixed)

switch to 64-bit time_t on x86_64

Reported by: korli Owned by: nobody
Priority: critical Milestone: R1/beta1
Component: System/POSIX Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

Description

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

Change History (12)

comment:1 by pulkomandy, 5 years ago

Milestone: R1Unscheduled

comment:2 by pulkomandy, 3 years ago

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…

comment:3 by waddlesplash, 3 years ago

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

comment:4 by kallisti5, 3 years ago

Milestone: UnscheduledR1/beta1
Priority: normalcritical

comment:5 by kallisti5, 3 years ago

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 ?

comment:6 by korli, 3 years ago

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.

comment:7 by kallisti5, 3 years ago

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

comment:8 by pulkomandy, 3 years ago

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.

comment:9 by waddlesplash, 3 years ago

Resolution: fixed
Status: newclosed

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

comment:10 by korli, 3 years ago

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.

comment:11 by waddlesplash, 3 years ago

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

comment:12 by kallisti5, 3 years ago

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

Note: See TracTickets for help on using tickets.