Discussion:
Error running MariaDB
Add Reply
issinoho
2020-10-08 14:29:35 UTC
Reply
Permalink
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)

Trying to install and run mariadb-5_5_68.zip (Berrymans)

$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR

Anyone have thoughts? What's DPML$SHR?

TIA
Ian Miller
2020-10-08 14:50:27 UTC
Reply
Permalink
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
issinoho
2020-10-08 16:18:14 UTC
Reply
Permalink
Post by Ian Miller
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
Thanks, Ian. How would a hobbyist get a hold of this ??
hb
2020-10-08 16:37:39 UTC
Reply
Permalink
Post by issinoho
Post by Ian Miller
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
Thanks, Ian. How would a hobbyist get a hold of this ??
$ help sys_files [syslib] DPML$SHR.EXE

SYS_FILES

[SYSLIB]

DPML$SHR.EXE

Portable Mathematics Library shareable image
$

$ help/mess SYMVECMIS
gives some hints, too.

If you can, you may want to relink mysqld so it references your
DPML$SHR. Or you may want to get the DPML$SHR.EXE file (or a compatible
shareable image) mysqld was linked against. Whether this is/was in a
patch kit escapes me.
John Reagan
2020-10-08 17:23:43 UTC
Reply
Permalink
Post by hb
Post by issinoho
Post by Ian Miller
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
Thanks, Ian. How would a hobbyist get a hold of this ??
$ help sys_files [syslib] DPML$SHR.EXE
SYS_FILES
[SYSLIB]
DPML$SHR.EXE
Portable Mathematics Library shareable image
$
$ help/mess SYMVECMIS
gives some hints, too.
If you can, you may want to relink mysqld so it references your
DPML$SHR. Or you may want to get the DPML$SHR.EXE file (or a compatible
shareable image) mysqld was linked against. Whether this is/was in a
patch kit escapes me.
That version of mysqld used a routine in the math library that is not present in the DPML$SHR on your system. Without more study or output from ANAL/IMAGE, we cannot tell which new math routine is used. Looking at the DPML history, there haven't not been many new routines added until recently for some of the C99 support.
hb
2020-10-08 17:33:12 UTC
Reply
Permalink
Post by John Reagan
Post by hb
Post by issinoho
Post by Ian Miller
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
Thanks, Ian. How would a hobbyist get a hold of this ??
$ help sys_files [syslib] DPML$SHR.EXE
SYS_FILES
[SYSLIB]
DPML$SHR.EXE
Portable Mathematics Library shareable image
$
$ help/mess SYMVECMIS
gives some hints, too.
If you can, you may want to relink mysqld so it references your
DPML$SHR. Or you may want to get the DPML$SHR.EXE file (or a compatible
shareable image) mysqld was linked against. Whether this is/was in a
patch kit escapes me.
That version of mysqld used a routine in the math library that is not present in the DPML$SHR on your system. Without more study or output from ANAL/IMAGE, we cannot tell which new math routine is used. Looking at the DPML history, there haven't not been many new routines added until recently for some of the C99 support.
It seems it uses MATH$FP_CLASS_TX and MATH$FP_CLASS_SX
.
John Reagan
2020-10-08 18:16:28 UTC
Reply
Permalink
Post by hb
Post by hb
Post by issinoho
Post by Ian Miller
Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_68.zip (Berrymans)
$ mysqld := $mysql055_root:[bin.Alpha]mysqld
$ mysqld
%IMGACT-F-SYMVECMIS, shareable image symbol vector table mismatch
-IMGACT-F-FIXUPERR, error when mysqld referenced DPML$SHR
Anyone have thoughts? What's DPML$SHR?
TIA
DPML$SHR - Double precision maths library - look for the DPML patch kit
Thanks, Ian. How would a hobbyist get a hold of this ??
$ help sys_files [syslib] DPML$SHR.EXE
SYS_FILES
[SYSLIB]
DPML$SHR.EXE
Portable Mathematics Library shareable image
$
$ help/mess SYMVECMIS
gives some hints, too.
If you can, you may want to relink mysqld so it references your
DPML$SHR. Or you may want to get the DPML$SHR.EXE file (or a compatible
shareable image) mysqld was linked against. Whether this is/was in a
patch kit escapes me.
That version of mysqld used a routine in the math library that is not present in the DPML$SHR on your system. Without more study or output from ANAL/IMAGE, we cannot tell which new math routine is used. Looking at the DPML history, there haven't not been many new routines added until recently for some of the C99 support.
It seems it uses MATH$FP_CLASS_TX and MATH$FP_CLASS_SX
.
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.
Stephen Hoffman
2020-10-08 20:42:10 UTC
Reply
Permalink
Post by John Reagan
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.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2020-10-08 23:07:22 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by John Reagan
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.

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).

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.

If I have left out any options, someone please fill me in.
John Reagan
2020-10-08 23:35:38 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
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.
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).
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.
If I have left out any options, someone please fill me in.
Using the older RTLs doesn't work for C since the problem is what the headers defined.

You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Those symbols are described in the CRTL reference manual.

The new fpclassify() work is guarded such that older __CRTL_VER will skip the definition of the new support
and the references to the new MATH$ entry points. The release notes for another RTL ECO kit will be clearer.

And yes, putting new functionality in remedial ECO kits is not something that has been done in the past.
issinoho
2020-10-09 08:47:24 UTC
Reply
Permalink
Post by John Reagan
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
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.
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).
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.
If I have left out any options, someone please fill me in.
Using the older RTLs doesn't work for C since the problem is what the headers defined.
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Those symbols are described in the CRTL reference manual.
The new fpclassify() work is guarded such that older __CRTL_VER will skip the definition of the new support
and the references to the new MATH$ entry points. The release notes for another RTL ECO kit will be clearer.
And yes, putting new functionality in remedial ECO kits is not something that has been done in the past.
Does ANAL/IMAGE list versions of libraries built against? All I could get was the following...

Shareable Image List

0) "DECC$SHR"
1) "CMA$TIS_SHR"
2) "LIBRTL"
3) "DPML$SHR"
4) "LIBOTS"
5) "PTHREAD$RTL"
6) "SYS$PUBLIC_VECTORS"

Also, where can I find, VMS842L1A_DPML V1.0 ?

TIA
Volker Halle
2020-10-09 09:34:32 UTC
Reply
Permalink
For shared library versions, you need to look at the 'Image Section Descriptors (ISD)' output of ANALYZE/IMAGE.

You should find an ISD for DPML$SHR, which contains information like this (example for MTHRTL):

global section major id: %X'81', minor id: %X'00800C'
match control: ISD$K_MATLEQ
global section name: "MTHRTL_001"

The patch VMS842L1A_DPML V1.0 must be obtained from VSI. You might register for the Community License Program (CL), but that does not currently seem to provide access to patches.

Or try an older version of MariaDB.

Or wait for a newer version of MariaDB, which solves this dependency problem.

Volker.
hb
2020-10-09 10:18:54 UTC
Reply
Permalink
Post by issinoho
Post by John Reagan
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Those symbols are described in the CRTL reference manual.
The new fpclassify() work is guarded such that older __CRTL_VER will skip the definition of the new support
and the references to the new MATH$ entry points. The release notes for another RTL ECO kit will be clearer.
And yes, putting new functionality in remedial ECO kits is not something that has been done in the past.
Does ANAL/IMAGE list versions of libraries built against? All I could get was the following...
Shareable Image List
0) "DECC$SHR"
1) "CMA$TIS_SHR"
2) "LIBRTL"
3) "DPML$SHR"
4) "LIBOTS"
5) "PTHREAD$RTL"
6) "SYS$PUBLIC_VECTORS"
There is no "version" of a shareable image recorded in the image. There
is only a Global Section MATCH control, which usually indicates whether
the order of entries in the symbol vector changed. Here the order did
not change (so the GSMATCH didn't change), but new entries were added.

ANALYZE/IMAGE for an image lists the shareable images it depends on. It
also shows the Global Section MATCH control. In its output look for
'global section name: "DPML$SHR_001"'. The preceding lines have the
GSMATCH info. You will see that this matches your DPML$SHR.

Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try to
find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in SYS$SHARE.
So ANALYZE/IMAGE can't detect this problem.

The new and here missing entries in the symbol vector of the shareable
image are detected at image activation time. That is, when the image
activator tries to resolve the references.

As already said, the sources need to be recompiled either on a system
without the CRTL ECO, probably your system, or with using the above
__CRTL_VER macro.
John Reagan
2020-10-09 11:54:32 UTC
Reply
Permalink
Post by hb
Post by issinoho
Post by John Reagan
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Those symbols are described in the CRTL reference manual.
The new fpclassify() work is guarded such that older __CRTL_VER will skip the definition of the new support
and the references to the new MATH$ entry points. The release notes for another RTL ECO kit will be clearer.
And yes, putting new functionality in remedial ECO kits is not something that has been done in the past.
Does ANAL/IMAGE list versions of libraries built against? All I could get was the following...
Shareable Image List
0) "DECC$SHR"
1) "CMA$TIS_SHR"
2) "LIBRTL"
3) "DPML$SHR"
4) "LIBOTS"
5) "PTHREAD$RTL"
6) "SYS$PUBLIC_VECTORS"
There is no "version" of a shareable image recorded in the image. There
is only a Global Section MATCH control, which usually indicates whether
the order of entries in the symbol vector changed. Here the order did
not change (so the GSMATCH didn't change), but new entries were added.
ANALYZE/IMAGE for an image lists the shareable images it depends on. It
also shows the Global Section MATCH control. In its output look for
'global section name: "DPML$SHR_001"'. The preceding lines have the
GSMATCH info. You will see that this matches your DPML$SHR.
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try to
find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in SYS$SHARE.
So ANALYZE/IMAGE can't detect this problem.
The new and here missing entries in the symbol vector of the shareable
image are detected at image activation time. That is, when the image
activator tries to resolve the references.
As already said, the sources need to be recompiled either on a system
without the CRTL ECO, probably your system, or with using the above
__CRTL_VER macro.
And we never bump the GSMATCH on any RTL anymore.

Consider this very case. If we had bumped the minor ID, then ANY program (even "helloworld.c") linked against the new RTL even if it didn't use something like fpclassify() would now demand that the new RTL be installed. Instead, we just rely on the missing symbol vector error message. Sadly, there is no way for the activating system to know a name of the missing routine.

We'd only bump the MAJOR ID if we decided to shuffle the symbol vector. And there is no reason for that. In such an extreme case, I'd just make new RTL with a different name.

The GSMATCH MAJOR,MINOR has its roots going all the way back to the VAX days where transfer vectors and the UNIVERSAL attribute didn't provide the ability to catch "going past the end of the vector".
Stephen Hoffman
2020-10-09 15:16:04 UTC
Reply
Permalink
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in SYS$SHARE.
So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2020-10-09 15:48:40 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in
SYS$SHARE.  So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
Or use a different tool:

$ shiml [.bin.alpha]mysqld.exe
recursive SHareable IMage dependency List (Alpha), version 1.5
[ -> translated logical name ] required match: ID [ / actual match: ID ]
[ (self) - self reference; (dnf) - duplicate, not followed ]

DECC$SHR -> SYS$SHARE:DECC$SHR_EV56 - MATLEQ: 1,1 / MATLEQ: 1,1
LIBRTL - MATLEQ: 1,1 / MATLEQ: 1,1
SYS$PUBLIC_VECTORS
SYS$BASE_IMAGE
CMA$TIS_SHR - MATLEQ: 1,5 / MATLEQ: 1,5
CMA$TIS_SHR (self)
LIBRTL - MATLEQ: 1,1 (dnf)
LIBOTS - MATLEQ: 1,3 / MATLEQ: 1,3
SYS$PUBLIC_VECTORS (dnf)
SYS$PUBLIC_VECTORS (dnf)
LIBOTS - MATLEQ: 1,3 (dnf)
DPML$SHR - MATLEQ: 1,0 / MATLEQ: 1,0
DPML$SHR (self)
LIBOTS - MATLEQ: 1,3 (dnf)
LIBRTL - MATLEQ: 1,1 (dnf)
CMA$TIS_SHR - MATLEQ: 1,5 (dnf)
SYS$PUBLIC_VECTORS (dnf)
SYS$PUBLIC_VECTORS (dnf)
CMA$TIS_SHR - MATLEQ: 1,5 (dnf)
LIBRTL - MATLEQ: 1,1 (dnf)
DPML$SHR - MATLEQ: 1,0 (dnf)
LIBOTS - MATLEQ: 1,3 (dnf)
PTHREAD$RTL - MATLEQ: 1,5 / MATLEQ: 1,5
PTHREAD$RTL (self)
CMA$TIS_SHR - MATLEQ: 1,5 (dnf)
LIBRTL - MATLEQ: 1,1 (dnf)
LIBOTS - MATLEQ: 1,3 (dnf)
SYS$PUBLIC_VECTORS (dnf)
SYS$BASE_IMAGE (dnf)
SYS$PUBLIC_VECTORS (dnf)
$
Stephen Hoffman
2020-10-09 22:45:59 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in SYS$SHARE. 
So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
That wasn't a request for alternative tooling.
--
Pure Personal Opinion | HoffmanLabs LLC
hb
2020-10-12 10:01:49 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the
image with the GSMATCH in the shareable on the system. It also does
not try to find out whether all the references to the shareable
image can be resolved from the shareable on the system, usually
found in SYS$SHARE.  So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
That wasn't a request for alternative tooling.
Maybe I don't understand, wouldn't be the first time. What should be
enhanced and analyzed better?

ANALYZE/IMAGE analyzes the contents of an executable image file or a
shareable image file, identifying obvious errors in the file. In other
words, it shows you every bit in the image file - and if that is in meta
data its meaning. That's all. Look at it as the VMS version of "objdump"
or readelf". Btw., the latter has some knowledge about VMS ELF images.

Checking for image dependencies, GSMATCH or whatever, is different.
Having this feature sounds useful, that's why the alternative tool was
written.

But there is no reason to enhance ANALYZE/IMAGE to do this. Code
sharing? Can be done without integrating the new feature into the
existing tool. (For several reasons the shown alternative tool does not
use code from ANALYZE.) You probably can integrate such a tool into a
DCL command like ANALYZE/IMAGE/DEPENDENCIES. Is that what you mean with
"Analyze better"? There is also a "SHOW IMAGE" and a qualifier
/DEPENDENCIES would make some sense there too, at least to me. But what
do I know.

Would you also suggest to enhance ANALYZE/OBJECT to check every external
reference whether a definition exists in a specified object or object
library and whether it is of a compatible type? It would detect
problems, which you currently only notice at link time!
Stephen Hoffman
2020-10-13 15:41:57 UTC
Reply
Permalink
Post by hb
Post by Stephen Hoffman
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in SYS$SHARE. 
So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
That wasn't a request for alternative tooling.
Maybe I don't understand, wouldn't be the first time. What should be
enhanced and analyzed better?
Because clearly that the image under analysis won't work on the local
system is somehow completely irrelevant to the image analysis being
performed?

For many of us, ANALYZE /IMAGE is a tool used as a pre-flight for the
sometimes-less-than-helpful image activator. To look for corrupt
images, and for the particular issues with images that won't launch.
The lesser-known DCL symbols are handy for scripting the pre-flight
checks, too. This because ANALYZE /IMAGE is what we have for file(1),
short of loading bintools or ilk or of creating our own tooling akin to
the image-shimming shimmer tool I wrote a while back.

It's also interesting seeing references to GSMATCH in this thread in
parallel to another thread discussing where GSMATCH usage has been
effectively deprecated within OpenVMS itself, too.

This whole area is archaic, and filled with arcane and tribal knowledge
and tribal tooling. With weird logical names that blow up some images,
and that are needed for other images. With no preferences and settings
support. No image signing. Requiring home-grown quota and compatibility
checks, which inevitably get omitted. Sandboxing and isolation and
integrity checks are missing. The whole area has endured ~forty years
of incremental hackery, and the resulting aggregation is overdue for an
overhaul. Because ~nobody understands the wrinkles and the limits and
the weird that is lurking here, and there's ~no documentation. What doc
does exist for various aspects of—but not all of—this area is scattered
all over; in DCL, in system services, in the IDSM, in the C docs, in
the Java docs, etc. (And yes, I know about polyglot
files—self-extracting zip files are one of the "better-known" polyglot
files encountered on OpenVMS.) But again, I do not expect to see image
activation and the current morass overhauled. Getting ANALYZE /IMAGE to
report "nope, not gonna work here" would be a stretch.
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2020-10-13 15:48:39 UTC
Reply
Permalink
The next C99/RTL ECO kit (almost complete) will include the following in the release notes. And we're also working on updates to the actual CRTL Reference Manual.

Note: If you develop an application on a system with the CRTL C99 or any later kit installed and intend it to be run on a system without those kits, you must compile your application with the switch /DEFINE=(__CRTL_VER_OVERRIDE=80400000).
issinoho
2020-10-13 16:26:57 UTC
Reply
Permalink
The next C99/RTL ECO kit (almost complete) will include the following in the release notes. And we're also working on updates to the actual CRTL Reference Manual.
Note: If you develop an application on a system with the CRTL C99 or any later kit installed and intend it to be run on a system without those kits, you must compile your application with the switch /DEFINE=(__CRTL_VER_OVERRIDE=80400000).
As a (partial) aside, what's the status of giving community users access to ECO kits?
Robert A. Brooks
2020-10-13 16:38:53 UTC
Reply
Permalink
Post by issinoho
As a (partial) aside, what's the status of giving community users access to ECO kits?
That's not an engineering decision.
--
-- Rob
John H. Reinhardt
2020-10-13 17:35:50 UTC
Reply
Permalink
Post by issinoho
As a (partial) aside, what's the status of giving community users access to ECO kits?
Make a lot of noise about it on the VSI OpenVMS Forum. <https://forum.vmssoftware.com/index.php>

More specifically, the "Community License Program - Questions & Answers" thread in "News & Development" <https://forum.vmssoftware.com/viewtopic.php?f=2&t=130>
and/or the "OpenVMS Community License Program" thread in "Off-Topic" <https://forum.vmssoftware.com/viewtopic.php?f=5&t=116>

The first thread is preferred for communicating with VSI staff.
--
John H. Reinhardt
hb
2020-10-09 16:08:59 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in
SYS$SHARE.  So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
... and another existing tool - although not written for such a check -
indicates what the problem is:

$ pipe xpd [.bin.alpha]mysqld.exe |search sys$pipe ":","could not",external
eXternal Procedure and Data list (Alpha), version 1.8
DECC$SHR:
CMA$TIS_SHR:
LIBRTL:
DPML$SHR:
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
LIBOTS:
PTHREAD$RTL:
SYS$PUBLIC_VECTORS:
$
issinoho
2020-10-09 16:56:14 UTC
Reply
Permalink
Post by hb
Post by Stephen Hoffman
Post by hb
Anyway, ANALYZE/IMAGE does not compare the GSMATCH found in the image
with the GSMATCH in the shareable on the system. It also does not try
to find out whether all the references to the shareable image can be
resolved from the shareable on the system, usually found in
SYS$SHARE. So ANALYZE/IMAGE can't detect this problem.
Fodder for enhancement, then: Analyze better.
... and another existing tool - although not written for such a check -
$ pipe xpd [.bin.alpha]mysqld.exe |search sys$pipe ":","could not",external
eXternal Procedure and Data list (Alpha), version 1.8
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x45f0 could not be symbolized
offset 0x4600 could not be symbolized
offset 0x4600 could not be symbolized
$
Ok, going back to mariadb-5_5_64 solves the problem so I'm guessing there was some modification to the build environment after that.

I now have another issue, but that's for another thread.

Thanks all.
Craig A. Berry
2020-10-09 15:49:39 UTC
Reply
Permalink
Post by John Reagan
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Good to know. I'm familiar with checking this in an ifdef but didn't
know it was user-settable.
Post by John Reagan
Those symbols are described in the CRTL reference manual.
Not that I can find. Nor does __CRTL_VER appear in

$ HELP CC Language_topics Predefined_macros
John Reagan
2020-10-09 20:39:59 UTC
Reply
Permalink
Post by John Reagan
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Good to know. I'm familiar with checking this in an ifdef but didn't
know it was user-settable.
Post by John Reagan
Those symbols are described in the CRTL reference manual.
Not that I can find. Nor does __CRTL_VER appear in
$ HELP CC Language_topics Predefined_macros
Ah, I confused the __VMS_VER symbol. There is a corresponding __CRTL_VER symbol
that you can see checked in the headers too. That was back from the days when
newer CRTLs would sometimes get put into compiler kits. How that we're trying to
put newer functionality into older remedial streams, we're back to the days when
__VMS_VER isn't good enough as it doesn't reflect what ECOs might be installed on
the system which provided a newer CRTL than what originally came with the system.

The V8.4 CRTL Manual, section 1.4.4, Multiple-Version-Support Macro

By default, the header files enable APIs in the HP C RTL provided by the version
of the operating system on which the compilation occurs. This is accomplished by
the predefined setting of the __VMS_VER macro, as described in the HP C User’s
Guide for OpenVMS Systems. For example, compiling on OpenVMS Version 6.2
causes only HP C RTL APIs from Version 6.2 and earlier to be made available.
Another example of the use of the __VMS_VER macro is support for the 64-bit
versions of HP C RTL functions available with OpenVMS Alpha Version 7.0
and higher. In all header files, functions that provide 64-bit support are
conditionalized so that they are visible only if __VMS_VER indicates a version of
OpenVMS that is greater than or equal to 7.0.

To target an older version of the operating system, do the following:

1. Define a logical DECC$SHR to point to the old version of DECC$SHR. The
compiler uses a table from DECC$SHR to perform routine name prefixing.

2. Define __VMS_VER appropriately, either with the /DEFINE qualifier or
with a combination of the #undef and #define preprocessor directives. With
/DEFINE, you may need to disable the warning regarding redefinition of a
predefined macro.

Targeting a newer version of the operating system might not always be possible.
For some versions, you can expect that the new DECC$SHR.EXE will require
new features of the operating system that are not present. For such versions, the
defining if the logical DECC$SHR in Step 1 would cause the compilation to fail.
To override the value of _ _VMS_VER, define __VMS_VER_OVERRIDE on the
compiler command line. Defining __VMS_VER_OVERRIDE without a value sets
__VMS_VER to the maximum value.
Mark Berryman
2020-10-09 17:07:49 UTC
Reply
Permalink
Post by John Reagan
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
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.
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).
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.
If I have left out any options, someone please fill me in.
Using the older RTLs doesn't work for C since the problem is what the headers defined.
You need to use /DEFINE=(__CRTL_VER=80400000) when you compile the code [or whatever the oldest version you want to support].
Those symbols are described in the CRTL reference manual.
Except that when you try that you get the following error:
%CXX-F-BADPREMACREDEF, incompatible redefinition of predefined macro
"__CRTL_VER"

MariaDB is full of C++ code.

Mark Berryman
Stephen Hoffman
2020-10-09 15:12:27 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Stephen Hoffman
Post by John Reagan
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.
Post by Craig A. Berry
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.
Post by Craig A. Berry
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.
Post by Craig A. Berry
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
Stephen Hoffman
2020-10-08 16:32:45 UTC
Reply
Permalink
Post by issinoho
Anyone have thoughts? What's DPML$SHR?
DIGITAL Portable Math Library.

That shareable was a re-write of the old VAX math library support into C.

You're running with a different version of that shareable than that kit
was built for, or (maybe?) that FreeAXP kit is somehow getting in the
way.

"DLL Hell" is always fun. Even on OpenVMS.

And no, there's no good way to package system dependencies within kits
on OpenVMS; no app bundles.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...