ZLib 0.04
Dave Higton (1515) 3477 posts |
Has anyone used the ZLib_Inflate SWI in version 0.04? Does it work for you? I want to recover some old files for testing, so I decided to recover them from backups I’d made with DBack, only to discover that DRest locks the machine, recoverable by Alt-Break. This used to work. I’ve tracked it so far to the call to ZLib_Inflate. I’ve got log lines from immediately before the call, but not after, so it appears that the call doesn’t return. Even converting it to the X form doesn’t return. After I started typing this, I realised that I have versions 0.02 and 0.03, with both of which DRest works! So there is an important difference between 0.04 and earlier ones. |
Rick Murray (539) 13747 posts |
What’s the provenance? Not so long ago a duff ZLib (compiler outputting bollocks) broke AcornHTTP… …and we all know how reliable module version numbers are these days. :-/ |
Dave Higton (1515) 3477 posts |
0.02 (30 Mar 2012) They must have come from updating HardDisc4 from time to time, as they aren’t in ROM and they are in the HardDisc4 image. I haven’t baked one for myself. They’re all about the same size. I’ve reverted to 0.03 in order to recover files from backup. To me, this is a serious problem, as DBack and DRest are published apps. Everyone who has used DBack to back up their files, and now has ZLib 0.04, will find their backups unrecoverable. (Unless and until they revert to an earlier ZLib, of course.) Presumably either 0.04 is defective or the API has changed without notice. |
Stuart Swales (8827) 1323 posts |
How big is it ;-) And what’s the datestamp, not the module title?
See https://www.riscosopen.org/forum/forums/11/topics/16239#posts-118296 As David Pitt wrote back then, ‘0.04’ does seem to be the ‘right length’; it is also that length in the current nightly HardDisc4 and the same in the release 5.28 HardDisc4. FWIW, my ‘0.03’s (I don’t have 0.04, awww) are of 2014 vintage. The git commit to bump to 0.04 seems to refer back to the last 0.03 being 2019! YMMV? FFS someone put a new version number on ZLib now that we know borked ones are out in the wild. I suppose this is a recurring danger – some nightly builds won’t be right, but eventually get merged with users’ !Boot etc. especially when they have been downloaded to obtain a.n.other module for which a fix has been known to be applied. |
David Pitt (3386) 1248 posts |
This is the update to ZLib Module 0.04 There is not much to it. There have also been change to the ZLib Library 1.20 which seems only to affect the Makefile. |
David Pitt (3386) 1248 posts |
Been here before then, I’d forgotten. |
Rick Murray (539) 13747 posts |
FFS, somebody modify the autobuilder so that modules that aren’t binary identical get a version bump automagically. We have different incarnations of mbedTLS in the same AcornSSL, and we have one of my programs actively interrogating parts of AcornHTTP to try to determine if it’s the good one or a broken one (because it crashes and takes out my program as collateral damage). This situation is ridiculous. The rule is quite simple. If Diff will say it’s not identical, then it should not carry the same module version number. No more excuses or sticking fingers in ears. |
Stuart Swales (8827) 1323 posts |
Better still, don’t complete the autobuilder for components that haven’t been changed but are now no longer identical. If they are no longer identical due to a known tooling change, then they MUST be bumped. |
Dave Higton (1515) 3477 posts |
Thanks for the pointers, guys, I had completely forgotten that history. I’ve got some big gaps between my downloads of HardDisc4, but here are a few reference points (date, length, OK/borked): 200225 45732 OK I don’t have any other HD4 images in those gaps between OK and Borked. Anyway, I’m up and running again – though I really ought to update the Help files of DBack and DRest to point out the pitfall. And I agree, now that the issue has been sorted, the version number ought to be bumped so that a good version is obvious. Until the next borkage, of course… |
Steve Pampling (1551) 8125 posts |
Well, as Rick (and the rest of the sane world) points out whatever the state of any module there is at least a identity marker for specific versions so spotting the difference is easier. |
Dave Higton (1515) 3477 posts |
While searching through my (outdated) sources of the disc image, I found a ZLib module that I must have built ages ago while trying to figure out how to build just AcornSSL. It’s the “borked” size. Now I’ll have to see whether my C tools are fully up to date (I might have updated them since that build), or whether they provide an explanation of any of the trouble I’ve been having with my builds of AcornSSL. |
Dave Higton (1515) 3477 posts |
I wonder how long the ROOL site was offering nightly builds of HardDisc4 that were borked? The ones I’ve tested suggest it could have been anywhere between 3 weeks and 9 months. And I wonder what else was borked, other than ZLib? |
Dave Higton (1515) 3477 posts |
I appear to have applied the 30a to 30b upgrade, but building HardDisc4 again still produces ZLib with the borked size. Maybe I have to remove the DDE installation and re-install DDE30 and its upgrades, from scratch. |
Stuart Swales (8827) 1323 posts |
Try cc -version. You should have 5.86 (10 Feb 2021) if you have either DDE30a or DDE30b. |
Stuart Swales (8827) 1323 posts |
Doesn’t the build process will cache your tools somewhere? Best start with a completely fresh build tree! |
Rick Murray (539) 13747 posts |
Yes. This one has caught me out too. Dunno why it can’t just use the ones specified by the DDE setup…
Might be quicker/less hassle to simply search the source stuff for “cc” to see where it is to replace it. 1 (cough) Charlotte Wessels and Floor Jensen/Marko Hietala, with a bit of Tobias Sammet from time to time (though, sadly, not all in the same song) (/cough) |
Dave Higton (1515) 3477 posts |
Ah… yes, they’re in every source tree, at Src.Disc.RiscOS.Library.Acorn. Thanks! |
Dave Higton (1515) 3477 posts |
The gotcha is that the InstallTools script only gets called once, so the cached tools don’t get updated – unless you know you have to do it. I hope I’ve now wasted enough of my time that the necessity is burned into my memory. |
Stuart Swales (8827) 1323 posts |
That’s really helpful to folk like me who copy them to RAM disc :-) |
Dave Higton (1515) 3477 posts |
They’re put there by the InstallTools script. If you mean you’d rather load them from RAM disc than from HDD, I guess we’re on to Rick’s question:
I agree. Since they have to be copied into their cache from a properly installed copy of the DDE, it follows that anyone building from source must have the DDE… so use the DDE from where it is. Or where the faster copy is, perhaps. The only “virtue” I see is that an update of the DDE will leave the build environment unchanged. Not much of a virtue, and it becomes a vice (is that the opposite of virtue in this context?!) when a bug-fixed DDE comes out. Unless you remember that you’re working from cached tools – which, clearly, some of us don’t. In fairness, where I used to work, the final builds had to be built on a build machine, which had to remain unchanged. The cached copy is a cheap equivalent, I suppose. So now it’s time to look at whether RISC OS source builds can be changed centrally (-ish) to use the installed rather than the cached DDE. |
Stuart Swales (8827) 1323 posts |
One small victory at Acorn was to get everything for the RISC OS 2 ROMs built consistently on a single system, which then went into the drawing office archive. I’d suffered before from getting software out of the D.O. only to find that it used an obsolete assembler on a system we no longer had any of… |
Stuart Swales (8827) 1323 posts |
If the intent is to have a fixed build environment that could be copied away for reproducible builds, it would seem sensible to have an Install Tools button that then greyed itself out. |
Stuart Swales (8827) 1323 posts |
These were inadvertently borked builds of the same source.
We are talking nightly builds here that people are being invited to test… |