Post by Craig A. BerryPost by Stephen HoffmanPost by John ReaganAs 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.
Post by Craig A. BerryIf 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.
Post by Craig A. BerryIf 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.
Post by Craig A. BerryIf 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