Link Errors

[Paul Coviello]

I'm trying als to get this to work and when I @build I get the following error.  any ideas? set ver is on

thanks

Paul

$ @build
$ cc/define=(_VMS_WAIT)/pref=all nrpe_aux,utils,custom,check_nrpe
%DCL-W-NOQUAL, qualifiers not allowed - supply only verb and parameters
 \DEFINE\
$ link nrpe_aux,utils,custom, a/opt
SYS$SHARE:SSL$LIBCRYPTO_SHR32.EXE/share
SYS$SHARE:SSL$LIBSSL_SHR32.EXE/share
%ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$b_ei_mag0' has invalid value %X08
 module: <unassigned>
 file: DSA1110:[PATCHES.NAGIOS]NRPE_AUX.OBJ;3
%ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$b_ei_mag0' has invalid value %X08
 module: <unassigned>
 file: DSA1110:[PATCHES.NAGIOS]UTILS.OBJ;3
%ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$b_ei_mag0' has invalid value %X08
 module: <unassigned>
 file: DSA1110:[PATCHES.NAGIOS]CUSTOM.OBJ;3
%ILINK-W-USRTFR, image DSA1110:[PATCHES.NAGIOS]NRPE_AUX.EXE;9 has no user transfer address
$

[Hoff]

Where did you get this kit from?  URL, please?

Turn on verification (SET VERIFY) in the procedure.  If the procedure manages verification itself, you may have to enable this differently; either a symbol or a logical name, or by editing the procedure directly to add the SET VERIFY command.  This to see exactly what's going on within the DCL.

There might well be a local "cc" symbol here, based on that odd /DEFINE diagnostic.  Look for (SHOW SYMBOL CC) and (if found) get rid of that (DELETE/SYMBOL) before invoking the build procedure.

The rest of the stuff looks like it isn't funding OpenVMS I64 objects; see if you're getting OpenVMS Alpha objects from somewhere, for instance.  (This is why you want to use the SET VERIFY.)

And please don't thread-jack unrelated questions; your C code compilation question is quite different from the base question.  And because this isn't your thread, you can't mark this thread closed, etc. 

[Paul Coviello]

ok I didn't mean to hijack a thread, my apology.. and I don't think I marked it closed, I only responded because it had to do with compiling the Nagios agent on IA64 with 8.3 1h1 which the OP had said he had done and yet when I try (and set verify is on)... I got the messages I did, and where I got the kit I don't remember, been to so many looking for a fix but downloaded all versions...

again my apologies for hijacking...

[Paul Coviello]

from here...

http://nrpevms.dbaalacarte.com/

[Hoff]

I've downloaded the 2.0b kit from what's posted there, unpacked it, and run a test build.  It's a very simple DCL build sequence, and it builds cleanly to completion on a test OpenVMS Alpha V8.4 box here.  (I haven't tested the resulting executable images.)

In your environment, issue the following DCL command:

$ SHOW SYMBOL CC

It looks like you have a CC symbol equated, and that it's messing up the build.

If you have a CC symbol (if the SHOW SYMBOL returns something other than "%DCL-W-UNDSYM, undefined symbol - check validity and spelling"), then issue the following two commands:

$ DELETEXYZ /SYMBOL /GLOBAL CC 

$ DELETEXYZ /SYMBOL /LOCAL CC

One of those two commands might (will?) generate an error; I'd guess that the /LOCAL command would fail.  And I'm also using an XYZ suffix on that DELETE command to bypass any site-specific DELETE symbol that might (also) be defined here; that XYZ is NOT a typo.

Then retry the @build sequence.

[Paul Coviello]

ok thanks I'm trying for an IA64 though!  might be my probelm :-(  also nothing shows up for sh symbol but if I issue cc at the prompt it is short for ccontrol a cache command... just don't know how it's defined.. :-(

thanks

Paul

[Hoff]

I know you are trying this on OpenVMS I64 V8.3-1H1.  That detail is, however, not particularly relevent to this error.  This is a generic error, and would show the same on OpenVMS VAX, OpenVMS Alpha or OpenVMS Itanium.

 
If you don't have a DCL symbol matching CC or such, then then something is probably setting up a DCL$PATH definition (with a CC image or CC procedure "in front of" the C compiler verb, or it's establishing a DCL command verb in the command tables; that's somewhat harder to spot, as you'll have to dig through the LOGIN.COM or the system-wide SYLOGIN.COM or in some procedure or tool that is invoked from those procedures looking for a SET COMMAND or a DEFINE DCL$PATH that's adding that verb or that tool to the command path, or somebody's added that verb into your DCL command tables system-wide.

As a starting point:
 

SHOW LOGICAL DCL$PATH

See if you have a CC.EXE or a CC.COM around somewhere.

Establishing a DCL symbol or a command verb (or a DCL$PATH) that overlaps the DCL verb of an unrelated utility - the CC symbol here is colliding with the CC command verb for the C compiler - is generally not considered best-practices.

Extracting the command verb from existing tables can involve the Freeware VERB, but that's probably more digging here than you'll want to discuss.

With that symbol (or command verb) present, you won't be able to use the C compiler.  While it is unlikely in this case, these sorts of DCL symbol-verb collisions may well result in an unintended consequence, too.

[Paul Coviello]

ok wasn't sure about that... yes I have found alot that has been assigned that I don't like... it was a former person,

been here since july so still working through everything...

well there is nothing for dcl$path  and nothing in sylogin or login for the system account, currently have a call into vendor as to where this is defined... can I over write it with what it should be?  

thanks

Paul

[Hoff]

If this is a conflicting command verb (your answers are a little terse for me to be entirely sure of the status of the current environment here), then you're headed toward reinstalling the C compiler kit (which will mess up anything else here that uses the existing CC verb) or extracting the CLD from the C compiler kit, and loading that into your process tables with a SET COMMAND.

List the PCSI C installation kit contents:

PRODUCT LIST C

Then find the CLD file in that listing, and extract it.

PRODUCT EXTRACT FILE C /SELECT=cld-filename

Then load the command definition

SET COMMAND cld-filename 

(I don't have a C installation kit for OpenVMS I64 handy on the local VMS server, and the target-practice testing Itanium server is presently occupied and inaccessable right now.)

I'd try that SET COMMAND sequence to re-add the C compiler command definition before I'd try a SET COMMAND /DELETE on the command verb here.  But you may end up attempting to delete the command verb from your local command tables.

(And for those following along at home, I'm intentionally avoiding suggesting the VERB tool from the OpenVMS Freeware; that's a bit more than is probably worth tangling with here.  And it'll potentially have to be built from its source code, and that might be a problem here as the VERB tool itself involves some C code.)

[Paul Coviello]

ccontrol is an executable that is for use with cache. and in a former life to run it we would use cco and not cc.

as far as prod list... and * doesn't work either

FACS1>prod list c
%PCSIUI-I-NOMATCH, no products were found matching: C
%PCSIUI-E-NOPROD, no products were found on which to perform this operation
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

[Hoff]

The PRODUCT LIST command fails because there is no C kit present in the default directory.  You'll need to have that kit present, as that's the source for the CLD file that is being retrieved here.

Using a ccontrol DCL verb (and particularly a DCL verb that is defined in a way that blocks the C compiler) is not something I'd consider good practice on OpenVMS.

I'd suggest acquiring an escalation and support path for your site, as well.  We haven't commenced with the configuration and any necessary troubleshooting with the tool that initiated this discussion; we're still just trying to get the base OpenVMS environment to work correctly.

[Paul Coviello]

already done... since I don't have C evidently. is there an additional cost for this?

thanks

[Paul Coviello]

the response :-(

Per Intersystems: the minimum command to start CCONTROL is CCON, and in their controlled tests this is how it behaves. However they too have seen this in uncontrolled tests. That is CCONTROL adopting the abbreviation of CC, and thus potentially masking the C Compiler. They do not know why this happens, but are inclined to blame poor design in the command definition utility. This is one part of OpenVMS with no diagnostics, effective listing or analysis utility, and there is no reliable way of removing commands out of sequence.

What they did suggest as a work a reasonable work around is to re-install the "C" Compiler. That should set things right. You could also ask HP for tools to analyze and edit your DCL command table, but re-installing the C Compiler would be a lot quicker.

[Hoff]

I'd get everybody on a conference call, and find the trigger and the resolution.  Get the Intersystems and HP support folks together, and find the fix for this.  (The Intersystems folks don't appear to be taking on the primary role for resolving this case, so you or someone your organization designates are probably going to own that primary role for now.  Having a known and confirmed case of the bug is - to me - interesting, too.)

If you want somebody else to review (part of) the trigger here, then we'll need to see the full CLD command definition for the CCONTROL tool.  (We can extract the CLD for the C compiler ourselves, but not everybody here has access to the Cache' software.)  The CLD is embedded somewhere the  Cache' software installation environment, but I don't know where that might be.  The other option is the VERB tool, and extracting it from the live DCLTABLES file.

To avoid the collision entirely, the brute-force fix is to create a parallel DCLTABLES file, and load the C verb into that, and use that while you're working with the compilers.  Or to delete the CCONTROL verb from the current (local) command table, and then load the C verb.  The former is rather more involved to set up and maintain than seems reasonable to document here, while the latter sequence was mentioned earlier in this thread.

Have a backup of the disk before I started working on the command tables.  Mistakes do happen.

I'd not have created a command verb that collides like this, but that's me.  My guess is that Intersystems is stuck with the fallout from that particular decision.

And yes, loading the C compiler again is simple.  But it really reeks of a hack-around for a bug that's here somewhere.