[Info-vax] Error running MariaDB

[Stephen Hoffman]

On 2020-10-08 23:07:22 +0000, Craig A. Berry said:

> On 10/8/20 3:42 PM, Stephen Hoffman wrote:
>> On 2020-10-08 18:16:28 +0000, John Reagan said:
>> 
>>> As yes, we extended fpclassify() and that seems to introduce the new 
>>> entry point definitions.   I'll pass this along to the engineers to see 
>>> what they think.
>> 
>> Prolly missing a dependency on VMS842L1I_DPML-V0100 (I64) or 
>> VMS842L1A_DPML V1.0 (Alpha)—the C99 kits don't list that as a 
>> dependency, though. OpenJDK does list that, though little else.
> 
> I'm pretty sure this is the first time a major (not entirely 
> compatible) CRTL change has been released outside of an OS release. So 
> developers who have always assumed if you provide binaries linked on an 
> 8.4.x system that is completely up-to-date on patches that it will run 
> on any 8.4.x system can no longer make that assumption.

C has had retrofits before, not the least of which was the ACRT K&R 
retrofit with then DEC C V4.0 back onto versions prior to V6.0.  And 
mismatched pthreads updates have been longstanding fodder for crashes, 
too. And this is far from the first time there've been fixes reconned 
within OpenVMS itself.

HPE was adding enhancements via V8.4 UPDATE kits, not that I'm entirely 
certain that those changes and enhancements ever got documented outside 
the UPDATE patch kit release notes.

Like HPE, VSI still suffers from the same inexplicable view that patch 
kit release notes are somehow secret. Somehow advertising the results 
of HPE and now VSI investments in sustaining work and the value of the 
HPE and now VSI support is deemed inappropriate fodder for what is also 
technical advertising. Missed marketing opportunity. Go figure.

> If you want to require anyone using your package to have the C99 
> features added recently, then you need to specify the C99 and DPML 
> updates in your PCSI dependencies or require some later version of VMS 
> (presumably v8.4-2L3 or later).

Yep, but should you add DPML to your prerequisites, you need carefully 
consider your prerequisite test syntax, lest your kit fail to install 
on V8.4-2L3J4ECO9 or whatever future release next integrates that DPML 
patch or that feature.

And as I've grumbled about this before, there's no good way to automate 
these checks at build-time or at run-time (no PCSI API, etc), so the 
whole morass gets handed to the documentation folks and then along to 
the kit installer and the support team.  This'll get yet more 
interesting with incompatible API changes, as (not if) those start to 
arrive—there was already one that's been discussed, but that API change 
has not yet been shipped AFAIK.

> If you want to provide binaries that work on systems without the C99 
> and DPML patches, then you either need to maintain unpatched systems 
> and build your releases on those, or do an unsupported dance with the 
> linker
> to make it see older libraries than what you have installed on your system.

Yep.  Back-linking is not without its occasional joyous moments, too.

IIRC, it was permissible to ship the ACRT bits with a kit akin to a 
home-grown package, but that shipping permission doesn't happen very 
often.

> If I have left out any options, someone please fill me in.

That's pretty much it.  Support for packages-like kitting would be nice 
here. The ability to package all the dependencies together. Though that 
don't yet exist on OpenVMS.  It'll tie into jails / sandboxes / 
containers, should that support arrive sometime after the arrival of 
the OpenVMS x86-64 port.

If VSI follows through on the rest of SaaS along with the licensing 
changes (including installing the updates), then as developers we'll be 
on V9.2 (or as they may then decide to call it, V10.0) for the 
foreseeable future, looking at build numbers or release dates or some 
such alternative to versions and UPDATE patches. Which'll mean we're 
then differently-dealing with these installation prerequisites. And if 
we're going to break PCSI and versioning and the rest with full-on 
SaaS, it'll hopefully be to better APIs and better schemes.


-- 
Pure Personal Opinion | HoffmanLabs LLC