🚀 go-pugleaf

In article <3eh21g$crt@crl5.crl.com>, cgi@crl.com (Paul Smith) writes:
|> Environment: UnixWare SVR4.2, version 1.1.2 (Intel)
|> 
|> We've bounded the system includes and our own library funcs with: 
|> #ifdef __cplusplus
|> extern "C" {
|> #endif
|> 
|> #include <sys/types.h>
|> 
|> #ifdef _cplusplus
|> }
|> #endif
|> 
|> We're getting started on c++ using an older version of c++, 2.4.3
|> and adding to the gcc cmd line: -D__STDC__ -D_XOPEN_SOURCE
|> and still hitting K&R style function declaratoins in the 
|> /usr/include/*/sys/* places.  I.E. sys/types.h
|> 
|> Is my recourse to hack the system includes for proper ANSI prototypes
|> that the native C compiler ignores.
|> 
|> FYI: after replacing acomp with a shell script to echo the cmd line args
|> passed to the preprocessor, to my either horror or ignorance, acomp has
|> imbedded the assersion of the std defines.  I.E. cc does not set the 
|> -D__STDC__ type of defines on the preprocessor cmd line, acomp, the 
|> SVR4.2 preprocess, has internalized these and -# switch does not cause
|> it to dump out what's going on???!*&%??!! 
|> 
|> How can I find out what defines
|> are TRUE for the native C compiler, so as to -Dxyz=1 on the gcc cmd line??
|> 
|> GCC 2.4.3 questoin:
|> 
|> It seems that -g is not supported by this version?  Does anyone have 
|> insights in the debug symbole generation?  Is a later(est) version
|> of gcc the way to go??
|> 
|> Any helps y'all can offer would be very much appreciated??
|> 
|> Thanks.
|> 

You may want to investigate getting the UnixWare C++ compilation system
2.0 for UnixWare 1.1.  We have some of the header files for C++ fixed up
in /usr/include/CC.  UnixWare 2.0 has the header files fixed up as well.
But, you currently probably have to fix up some of the headers to work.
In terms of the std defines, the cc man page outlines some of them as well
as when you turn on options such as -Xt.

Darren R. Davis
UnixWare Developer Support Engineer
Novell Developer Support