CLib568 / FreeTime conflict
Colin Ferris (399) 1814 posts |
Using CLib568 and !FreeTime !RunImage dated 14Dec 02. |
Colin Ferris (399) 1814 posts |
That’s with a RPC SA RO4.02. |
Sprow (202) 1158 posts |
Looking at the source code it does timehere = time(NULL); which exactly corresponds to the fix in CLib 5.68 to make time() return UTC values. FreeTime is self inconsistent – in 4 other places it doesn’t do that – odd. I’ve compiled a version which you may wish to try to see if I analysed it right. If I have, I’ll try and remember my sourceforge password to make it official (in theory, a run time check could be made for a fixed CLib and the old code used for anyone who hasn’t updated). |
Colin Ferris (399) 1814 posts |
Using a SA RPC RO4.02 |
Sprow (202) 1158 posts |
Referring to your original question, I think the combinations worth trying (and my anticipated outcomes) are:
You’ll need to reboot between the above tests, since the CLib is a rather important component and should be loaded early in the boot sequence. |
Colin Ferris (399) 1814 posts |
CLib 5.68 and your !RunImage file inserted into !FreeTime. |
Sprow (202) 1158 posts |
OK, I probably missed something (I just did a search & replace, no brain juice was used in the process). I’ll try to remember to look at it again… |
Colin Ferris (399) 1814 posts |
Repeated attempts to run/update the clock – just says - |
Colin Ferris (399) 1814 posts |
Running the 17Jun12 !RunImage FreeTime with RO 5.19 19Jun12 produces the same effect as RO4.02. |
Doug Webb (190) 1180 posts |
Ok tried this and get the same issue. Sprows updated RunImage in !Freetime,SharedCLib 5.69, latest ROM and HardDisc images dated 25th June. Manually set clock back 2 minutes , run Freetime and it says Clock running xxx , accept changes and it puts time back one hour. Hope this helps. Doug |
Sprow (202) 1158 posts |
I’ve not looked at this yet, other than remembering to check out the configuration half of !FreeTime. I’ll post here when there’s another run image to try. |