ZLib 0.04

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.

This used to work.

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

What’s the provenance?

0.02 (30 Mar 2012)
0.03 (03 Jan 2018)
0.04 (18 Jan 2020)

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.

How big is it ;-) And what’s the datestamp, not the module title?

Not so long ago a duff ZLib…

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.

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.

As David Pitt wrote, ‘0.04’

Been here before then, I’d forgotten.

FFS someone put a new version number on ZLib now that we know borked ones are out in the wild.

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.

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.

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
200319 45732 OK
200426 45732 OK
200820 45736 OK
210109 45836 Borked
210202 45836 Borked
210520 45736 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…

Until the next borkage, of course…

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.

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.

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?

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.

Try cc -version. You should have 5.86 (10 Feb 2021) if you have either DDE30a or DDE30b.

Doesn’t the build process will cache your tools somewhere? Best start with a completely fresh build tree!

Doesn’t the build process will cache your tools somewhere?

Yes. This one has caught me out too. Dunno why it can’t just use the ones specified by the DDE setup…

Best start with a completely fresh build tree!

Might be quicker/less hassle to simply search the source stuff for “cc” to see where it is to replace it.
[I’d tell you myself, but I got up at five for an extra day at work, so I’m lying in bed with a mobile phone, some peaceful music ¹, and a hot chocolate]

¹ (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)

Doesn’t the build process will cache your tools somewhere?

Ah… yes, they’re in every source tree, at Src.Disc.RiscOS.Library.Acorn.

Thanks!

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.

Ah… yes, they’re in every source tree, at Src.Disc.RiscOS.Library.Acorn.

That’s really helpful to folk like me who copy them to RAM disc :-)

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:

Dunno why it can’t just use the ones specified by the DDE setup…

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.

In fairness, where I used to work, the final builds had to be built on a build machine, which had to remain unchanged.

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…

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.

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.

These were inadvertently borked builds of the same source.

Any updates to a given product (module, lib, util, application, etc) should be tested to work without breaking backwards compatibility before it is posted, as much as possible to test.

We are talking nightly builds here that people are being invited to test…