When does sys$starlet_c.tlb get updated?

[OwensJ]

We had a machine which used to build C/C++ projects that crashed, and put the same versions of the C/CXX compilers (7.2-1) on new machines running OpenVMS 8.3I with Update7. The problem is, code that compiled with the same compiler versions on our old build machine no longer compiles. When we researched it, it looks like the sys$starlet_c.tlb file is older on the new machines than it was on the old machine.

There were 2 additional comments at the top of the otsroutines.h from 2006 and 2007 on our old box, which do not exist in the same file on the new box. The summaries of which were:

20-MAR-2007 JML QXCM1000393572 Headers returning complex results can't be compiled by BASIC.

and

14-Dec-2006 JML QXCM1000384200 Headers returning complex results can't be compiled by C/C++ (Which seems to be where our issue is residing)

If we use the sys$starlet_c.tlb from the older machine that has those comments in the otsroutines.h to the new machines, the compile works. Yes, I am aware that this -may- be our solution, but what we really want to know is how to officially update those files to bring them up to date, because apparantly installing to I64_8.3I with Update7 Path, C V7.2-1 and CXX 7.2-1 do not update those files where we need them to be.

[John Gillings]

John,

Good question!

STARLET libraries belong to the operating system, so (technically) they should only be updated with OpenVMS, or when the OS is patched.

On the other hand, sometimes newer versions of some compilers may need to have updated libraries for various reasons.

In the past, compiler kits have sometimes updated system libraries. Some compilers ask if you want to rebuild libraries. Arguably language specific libraries should belong to the compiler, but then things like STARLET have strong dependencies on the OS, so it's not black and white.

Similar questions arise with language RTLs. Historically compiler versions which "stole" ownership from the OS and distributed updated RTLs in compiler kits have caused trouble from time to time. There is more exposure to potential conflicts with RTLs because they impact running programs, not just compilations.

Unfortunately, whichever path is taken, there will always be update sequences which result in unexpected differences. To track down the exact sequence, you may need to correlate installations and patches on the two systems.

To some extent, the INCLUDE files provided by STARLET are "advisory". That is, you could write your own (at least, in theory!), so you don't need to take whatever you get as gospel.

If you've found a discrepancy, I'd suggest using the library which works. Be aware of the difference, and keep a careful eye on any patches applied. If you want to take the cautious path, restore the "correct" (original?) library before installing any update or patch.

[Hoff]

To answer your implementation question, SYS$STARLET_C.TLB is updated with VMS and with various patches (PTHREAD patches had it for a while, in older versions).

This text library is entirely dependent on the VMS version.

As for another question seeking an official fix, ITRC isn't an official forum. Your chances of getting an official answer here (and particularly with the unfortunate lack of diagnostics and lack of source code) is comparatively low. Please call the support center.

HP (or whomever you contact for support) will need to see the diagnostics and possibly the source code of a reproducer. HP have a look at the PTR details associated with QXCM1000393572, and see what's up, and whether your source code modules and compilation errors match up with the OTS$ROUTINE.H definition changes.

This could well be entirely unrelated to the OTS changes, too. This wouldn't be the first time an upgrade broke something. This may be as simple as a LIBRARY /REPLACE command (from a module HP provides or from V8.3-1H1 or V8.4, or a patch kit with updates to the library, etc) or there may well be something entirely else wrong here, as this could be unrelated to the OTS$ declaration changes.

Call HP or your support provider.

[OwensJ]

A lot of interesting information! I had hoped that maybe it would be a cut and dry thing, but it looks like there are so many possible causes that an exact solution may not even be possible. I was thankful that at least we could trace good and bad versions of the files we needed, but looks like we may just have to do some independent testing to see how to re-create a good result.

I'll take a look at the files in question on a base 8.3 installation, followed by the pthread patch, the update 7 kit, the C compiler, and the C++ compiler, and see how it changes, if at all.

[OwensJ]

So far, off a base 8.3 Install I've installed

PCSI V2.0
C V7.2-1
CXX V7.2-18
Update-V0700

And none have which updated starlet yet past the initial 2006 version. It's like digging for a needle in a haystack!

[Andy Bustamante]

You might try searching sys$help:*.release_notes for mention of sus$starlet_c.tlb

Opening a case with HP and having them dig for this change is another option.

[OwensJ]

Yeah I hopened a case with HP yesterday. I plan to post the answer to the question if I get it from them.

[abrsvc]

Please post the first page output from an ANAL/IMAGE/HEADER for each of hte RTLs. The data and IDs should give us a clue.

Dan

[OwensJ]

Can you elaborate a little more? When you say "each of the RTLs" I'm a little confused. I'm only having an issue with the sys$starlet_c.tlb file (or some of its contents). If I replace it with a newer one everything we have compiles fine. I just want to know what patch updates it (if any). Do you need me to run that anal/image/header on the sys$starlet_c.tlb file? or some of its contents?

[OwensJ]

Andy,

I did a search so far of all of the .release_notes and the only mention outside of the CC.release_notes is some steps to update sys$starlet_c.tlb in the sys-V0200 patch, but that is an unrelated fix.

-John