[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with c89 and c++ on z/OS
Re: problems with c89 and c++ on z/OS
Tue, 2 Jul 2002 17:25:57 -0400
First, let me disclaim all statements here: I do not speak for IBM, these
are my own observations.
Second, to understand the philosophical bent of the z/OS Unix System
Services shell & utilities implementation, you need to refer to the Open
Group's Single Unix Standard, Version 2. This is the certification that was
targeted (and acheived) by the implementors of USS so that they could
obtain the Unix brand. Many of your answers will be found here, with a
Thirdly, I've numbered your questions so I can respond numerically to them
1) SUS V2 is the reason for the strange warnings here. See their definition
for the "trap" shell built-in. Note carefully that SIGPIPE is not defined
by number. "trap SIGPIPE" certainly works without errors.
2) I know of no way to make "c89" preferred over "cc". I'd suppose running
config.guess and config.sub, then parsing out the value, would be the thing
to do here, and set CC accordingly. It's lame, but it works. Again, I point
you to SUS V2 ... "cc" is marked "(LEGACY)", and we all know that LEGACY
== BAD :-)
3) Neither -v nor -V means "show me your version". -v emits JCL what the
compiler front end would emit in comparable JCL (don't go there), and -V
means "emit the listing to stdout". Neither of these switches is defined in
the SUS. You are correct: all four compiler front-ends eventually call the
4) The default source file suffix is controlled by a set of environment
variables. To force the "c++" front end to accept files suffixed in ".cc",
you need to export/set _CXX_CXXSUFFIX=cc -- this is the only other way I
know of than to alter CXXFLAGS. Note that there are three sets of each
environment variable depending on the front end in use: _C89 is the prefix
for the c89 f/e, _CC is the prefix for the cc f/e, and _CXX is the prefix
that affects both c++ and cxx.
5) I guess -Wc,HALT(4) must not have done this for you. I have no other
suggestions, since I don't have a reference copy of the ISO C standard
document. This compiler has been the subject of many bug reports. We might
have one here. If someone can quote me chapter and verse from the Standard
on the required behavior, I'll be happy to file a bug report against it.
James S. Tison
Senior Software Engineer
TPF Laboratory / Architecture
+1 203 486-2835 (voice/fax)
<address@hidden> To: address@hidden
Subject: problems with c89 and
c++ on z/OS
Here a list of problems with autoconf on z/OS, using native C and C++
compilers. AFAIK, g++ hasn't been ported (yet).
1 . Perhaps a cosmetic thing only: The value `13' in the signal list
for `trap' causes a warning message about an `unusual trap signal'
or something similar. I've checked the list for signals for z/OS
against my Linux box; the used values in autoconf are the same.
Perhaps it is a good idea to redirect the output to /dev/null to
suppress this warning message.
Mike, James, why does SIGPIPE (which is value 13) cause this
2 . The ANSI C compiler on z/OS is called c89; cc is a K&R compiler.
Is there a way to make autoconf automatically prefer c89 over cc
on this platform to avoid a `CC=c89'?
3 . c89, cc, and c++ (those three forms are only different front ends
to a single compiler, AFAIK) need an argument (a valid source
file) to make the switches -v and -V work. The first line of the
data returned by -V gives the compiler version. -v is rather
useless; the rest of the -V data isn't useful either for autoconf.
Akim already answered to me that calling both -v and -V with an
argument will be soon in autoconf.
4 . c++ doesn't accept the suffix `.cc' for C++ files by default. It
needs the option `-+' to do that. I would like to have autoconf
add that automatically.
5 . The major problem with c89 and cc (but not with c++) on z/OS is
that a missing header file doesn't produce a fatal return code.
This is weird, and I don't know whether this is the correct
behaviour regarding to the C standard... Anyway, it makes a lot of
autoconf's tests returning incorrect results.
Looking into the config.log file (which I've already sent to Akim)
I can see that the test for sys/dir.h correctly finds out that
this file doesn't exist. My question now: Is it possible to use
this double test (preprocessor/compiler) for checking all header
files? Alternatively, can autoconf be forced to do that?
Ideally, autoconf should do that automatically if running on the
BTW, the missing header file in question is `stdint.h'.