New C version = some problems

[Willem Grooters]

I have an old program, build originally on VAX.
It has been compiled and linked on Alpha, VMS 6.2, DECC 5.0-003, using flags /STANDARD=VAX.

Now we're on a new machine, VMS 7.3-1, C V6.5-001. So we run into a number of problems when building.

Compiling requires /STANDARD=VAXC otherwise one(!) modules fail to compile (unknown identifier EXIT_OK) and /NOWARNING to suppress a large number of messages - most of them -I-, some -W-, none appear to cause a problem.

Link gives me a problem, however.
Without any specific options, I finally get the message:

%LINK-W-MULDEF, symbol DECC$UNLINK multiply defined

in module DECC$SHR_EV56 file SYS$COMMON:[SYSLIB]DECC$SHR_EV56.EXE;1

We checked documentation and found a document "DECC$CRTL.README", titled "DECC$CRTL components On Compaq C and C++ kits", dated 1999. Chapter 5 concerns the problem: "Resolving Multiply defined DECC$ symbols". We did follow the recommendation to create DECC$EMPTY.EXE as a shared image and the definition of DECC$SHR. Now we get:

LINK-W-MULDEF, symbol DECC$UNLINK multiply defined

in module C$VAXCVECTORS file SYS$COMMON:[SYSLIB]STARLET.OLB;1

However: the program DOES run, without a problem (appearantly, I did n't encounter a crash...))

Two questions:
1. Do I have to change the code to get rid of -I- and -W- on compilation, or which at least? (It may depend on the message)
2. How to get rid of the MULDEF warning?

[Craig A Berry · Accepted solution]

The unlink() function was formerly unavailable from the CRTL so people tended to build their own. Looking at the version dependency tables in Appendix A of the CRTL manual, you can see that unlink became available in VMS version 7.0. Perhaps the most robust way to avoid the conflict would be to make sure the replacment function is only visible to the compiler when necessary with something like the following:

#if !defined(__CRTL_VER) || (__CRTL_VER < 70000000)

[ home-made unlink() replacement ]

#endif

That way you'd get the CRTL version of unlink when available and the home-grown one otherwise.

The easiest way to get it to compile, though, would be to compile with

$ cc/prefix=exclude=unlink

This would cause your code to always use the home-grown unlink and ignore the one in the CRTL.

Ignoring all the other warnings is a bit risky as a long-term strategy. Whether you can get away with it is really more of a business question than a technical one. If the program is "good enough" for whatever it is doing and is not likely to be under further development, then it may not be worth the time to fix it. On the other hand, if it's doing something important and will continue to be used indefinitely, then I'd recommend investing the time to fix it, including getting rid of the /standard=vaxc option and dealing with all the additional warnings that will generate.

[Martin P.J. Zinser]

Hello Willem,

Craig covered unlink. Just one more note, somewhere in doc there is actually a table that will give you the information exactly which version did add which function to the RTL.

As for EXIT_OK, this is most probably just a macro to indicate a success status, i.e. a

#define EXIT_OK

should take care of it. Now, what the value is supposed to be you will have to check in your sources. Typical values are 0 or 1 (and which of these depends on if the programmer has more of a C or more of a VMS background ;-).

I do seriously recommend getting rid of /stand=vaxc and fixing all the messages. Getting used to screens of stuff scrolling by at compile time is a sure ticket to missing problems when they creep up.

Greetings, Martin

[Willem Grooters]

Craig - it did the job. Thanks.
Martin - I agree we should get rid of the messages but I found than just finding out all required ones only, takes too much time to be handled in within the available timeframe. Also, most of them are cuased by missing prototypes, incorrect definition of subroutines (non-void but no return value, for instance) and so on. Nothing very bad, it has been taht way for years, and at least, the program runs properly. Whenever there is a problem, it will be dealt with, but for the moment we don't do anything about it.

[Ian Miller.]

I agree with Martin on his point that its worth spending the time getting rid of the warnings. It results in more maintainable code which avoids problems however I can see justification of this effort to management is sometimes a problem. The DECC compiler does a much better job of spotting questionable practices and its informational messages and warnings should be heeded.