topic Re: compilation error in Operating System - OpenVMS

compilation error

YE LIU_1 — Wed, 15 Oct 2008 14:01:58 GMT

Dear VMS Users,

I come across the following compilation when compiling string.cpp, which is enclosed. My guess is that I miss defining a macro so that I will not use multiple byte string. Could you give your opinion?

Thanks,

YE LIU

CXX /DEFINE=(USE_MULTINET,_DECC_V4_SOURCE,__DECC)/show=include/list /USING_STD /UNDEF=(_MBSTATE_T) string.cpp

typedef mbstate_t state_type;
............^
%CXX-E-UNDECLARED, identifier "mbstate_t" is undefined
at line number 192 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

typedef mbstate_t state_type;
............^
%CXX-E-UNDECLARED, identifier "mbstate_t" is undefined
at line number 291 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

typedef mbstate_t state_type;
............^
%CXX-E-UNDECLARED, identifier "mbstate_t" is undefined
at line number 387 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

return wmemcmp (__s1, __s2, __n);
...............^
%CXX-E-UNDECLARED, identifier "wmemcmp" is undefined
at line number 409 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

return _RWSTD_STATIC_CAST (const char_type*,
...............^
%CXX-E-UNDECLARED, identifier "wmemchr" is undefined
at line number 437 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

wmemmove (__s1, __s2, __n);
........^
%CXX-E-UNDECLARED, identifier "wmemmove" is undefined
at line number 455 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

wmemset (__s, __a, __n);
........^
%CXX-E-UNDECLARED, identifier "wmemset" is undefined
at line number 472 in module RW_INTERNAL_TRAITS.H of text library SYS$COMMON:[SYSLIB]CXXL$ANSI_DEF.TLB;1

Re: compilation error

Hoff — Wed, 15 Oct 2008 15:10:58 GMT

It appears the requisite inclusion of needed for the wmemset call and other functions was omitted from the compilation unit.

Re: compilation error

YE LIU_1 — Wed, 15 Oct 2008 15:19:09 GMT

Did you look at the source code before you replied?

YE LIU

Re: compilation error

Gregg Parmentier — Wed, 15 Oct 2008 15:34:47 GMT

you're including cwchar, not cwchar.h

does that matter?

does the order you reference matter?

Re: compilation error

YE LIU_1 — Wed, 15 Oct 2008 15:47:02 GMT

That is what I want to find out. BTW, I include wchar.h and it still does not work.

YE LIU

Re: compilation error

Hoff — Wed, 15 Oct 2008 15:51:12 GMT

As it turns out, I did compile the wrong file; and I had another random CXX laying around that built cleanly. Time to clean up the ITRC scratch area, apparently.

But having sorted that boo-boo out, the code gets the following build error:

$ cxx x

#include "SocketMisc.h"
.......................^
%CXX-E-SRCFILNOOPEN, could not open source file "SocketMisc.h"
at line number 39 in file ...X.CXX;20

That header file was missing from the test build, and the test box doesn't use Multinet. Either of these could send the compilation off the rails. (And I don't see the header file with the inclusion.)

The code wasn't compiled with V4 (that's very old), and the compilation didn't disable the _MBSTATE_T, and didn't select Multinet as none of those appeared (directly) in the source code. No Multinet here, too. Interestingly, the code itself doesn't actually check the Multinet settings before it loads a pile of Multinet includes; it's surprised the compilation pass didn't flag those, too.

It wouldn't surprise me that the wchar stuff isn't compatible with the V4-vintage C code, either.

What compiler version, and what platform?

Got a more complete example or that header file?

Re: compilation error

YE LIU_1 — Wed, 15 Oct 2008 15:53:18 GMT

You can remove that line.

YE LIU

Re: compilation error

Hoff — Wed, 15 Oct 2008 15:58:57 GMT

There doesn't seem to be a reason for the Multinet stuff, so I removed it. After removing various header files and some pieces, the (unmodified) code builds cleanly.

Here's the prolog code...

#include
#include
#include
#include
#include
#include
#include
#include

#include

#ifndef _RWSTD_HEADER_REQUIRES_HPP
#include
#else
#include
#endif

#ifdef __USE_STD_IOSTREAM
#include
#else
#include
#endif
#include
#include
#include

#include

int main ()
{
{remainder of code unchanged}

Re: compilation error

YE LIU_1 — Wed, 15 Oct 2008 16:04:33 GMT

I used this command to compile:

CXX /DEFINE=(_DECC_V4_SOURCE,__DECC)/show=include/list /USING_STD string.cpp

when I removed _DECC_V4_SOURCE, it works.

YE LIU

Re: compilation error

Hoff — Wed, 15 Oct 2008 16:16:49 GMT

So this appears to involve what is effectively lying to the compiler -- this isn't really V4-vintage source code -- and that got caught out.

Or in your more succinct description, that "doesn't work".

Is there a particular reason for the (sorry!) somewhat scatter-shot source code here (is this a cut-down example from something larger?) or for (in general) the use of the V4 compiler knob here?

Re: compilation error

YE LIU_1 — Wed, 15 Oct 2008 16:25:32 GMT

Hi, Hoff

It works means it compiles and yes I cut and pasted the head files from my project to the example C++ programs provided by VMS. I need define _DECC_V4_SOURCE in order to use multinet and I still have the same problem.

YE LIU

Re: compilation error

Hoff — Wed, 15 Oct 2008 16:55:30 GMT

Seems you're left with a choice: upgrade the C++ code to a more current instantiation of the compiler, or rework the C++ code for source compatibility with the V4 compiler instantiation (these being the two overt resolutions of the "don't lie to the C++ compiler" maxim) or split the compilation into multiple modules.

As a general rule, staying on old versions of software or hardware isn't a viable long-term strategy. It works for a while, though you eventually do get to pay to upgrade or to port or to fix the issues that inevitably crop up. And in any case, these messes and these choices tend to get punted up to management for a decision.

As (another) general rule, it's been my experience that these cases can sometimes be the result of some simple error that somebody used the compatibility setting to paper over; it might well be feasible to move forward by fixing a few bugs that more recent compilers have noticed. That the use of the old compatibility can be a legacy of a long-forgotten quick fix. I've also worked various cases where the compiler knobs were inexplicably set to suppress actual and real source code errors; the continued use of /STANDARD=VAXC being a salient example of this with the C compiler.

The best choice here depends on the project goals and budget and timeframe.