RE: cgicc compile on HP-UX 11.11 using aCC

[JACQUOT,BRYAN (HP-FtCollins,ex1)]

Hello,

Thanks for getting back to me.  I have responded to your
questions below.  There is one other issue I discovered after
sending my initial email yesterday.

When using the aCC compiler to compile the demos programs,
the -AA argument is also required (same issue).  However,
the libraries are different.  

Instead of setting LIB in demo/Makefile to: 

LIB = -lstdc++

it must be:

LIB = -lstd_v2 -lCsup_v2 

Thanks again for your help.

Bryan Jacquot

> -----Original Message-----
> From: Stephen F. Booth [mailto:address@hidden
> Sent: Wednesday, January 09, 2002 6:55 AM
> To: 'Bryan Jacquot'; address@hidden
> Cc: address@hidden
> Subject: RE: cgicc compile on HP-UX 11.11 using aCC
> 
> 
> I'll try to address your two issues separately:
> 
> > I was able to compile cgicc version 3.1.5 on HP-UX 11.11 using the
> > HP aCC c++ compiler (version C.03.26).  However, I had to make the
> > following changes.
> > 
> > I would appreciate it if these changes could be included in the next
> > version of cgicc.
> 
> I'll be happy to incorporate the changes, but I have a few 
> questions to
> help clear things up in my head.
> 
> > 1)  The HP aCC compilter requires a -AA compiler option in order
> >     to compile ANSI C++ code.  I couldn't figure out a way to do
> >     this via configure (although there may be a way.)
> > 
> >     To resolve this issue, I changed line 94 of the cgicc/Makefile
> > 
> >     from:
> > 
> >     DEFS = -DHAVE_CONFIG_H -I. -I$(srcdir) -I.
> > 
> >     to:
> > 
> >     DEFS = -DHAVE_CONFIG_H -I. -I$(srcdir) -I. -AA
> 
> Is there a way with aCC to tell the compiler type?  For example, if at
> configure time cgicc detects g++ it enables some verbose warnings and
> things of that nature.  But I need to know a command line 
> switch and the
> output so I can grep for a version string or type information.  Just
> something simple like
> 
> % aCC -v
> 
> which produces 
> 
> HP C++ compiler ...
> 
> Or something that will uniquely identify that compiler so I can
> selectively enable the switch.
> 

Yes, you can run:

% aCC -V
aCC: HP ANSI C++ B3910B A.03.26

Now, this gets a little tricky.  I'm assuming you want to make the
configure script as generic as possible, so I did a little digging
to try to figure out when the -AA option was introduced.  Without
the -AA option, namespaces are not supported, header files
are different (i.e. there is no <iostream> header file), and libraries
are different.  So its a big deal.

I assume there are at least two ways you could solve this.  First,
you could check for the aCC compiler and then try the -AA argument
to see if it works, or you could compare on the version numbers.
The later would be quite tricky, as there are now three release
streams for aCC, so you would need to check for:
        at least A.01.21 on HP-UX 10x,
        at least A.03.26 on HP-UX 11x, or
        at least A.05.30 on HP-UX 11.20

I don't have easy access to an old version of aCC, so I don't know if
grep'ing for 'ANSCI C++' is safe.  If you want me to check further on
this, let me know and I can figure it out.  However, from looking at
the configure script, I think a common practice is to try it out, if
it works it must be supported, so that would probably be the easiest
solution here?

> > 2)  The MStreamable.cpp file is missing the CGICC_BEGIN_NAMESPACE,
> >     and CGICC_END_NAMESPACE macros at the beginning and end of the
> >     file.  I'm not sure why it compiles correctly with gcc, but the
> >     HP aCC compiler gave compiler errors without these macros.
> > 
> >     Here's the (HP) diff -e output to fix the problem:
> > 
> > BEGIN--------------------------------------------
> > 36a
> > 
> > CGICC_END_NAMESPACE
> > .
> > 26a
> > CGICC_BEGIN_NAMESPACE
> > 
> > .
> > END----------------------------------------------
> 
> I'm not sure that MStreamable.cpp needs to have those macros- 
> my general
> approach is that in longer cpp files I will use those macros, but in
> shorter files like MStreamable I use the CGICCNS macro which usually
> expands to 'cgicc::', which should take care of the scoping.  I'm not
> sure why it didn't work.  If you look at the pre-processed output is
> there actually a namespace qualifier in front of the 
> streaming operator?

Yes, here's (some of) the output from the preprocessor:

#line 30
 std:: ostream&
 cgicc:: operator<<( std:: ostream& out,
 const MStreamable& obj)
{
 obj.render(out);
 return out;
}

Here are the compile errors I get when I don't include those macros:
(The compiler can't find the def'n for the MStreamable class.)

aCC -DHAVE_CONFIG_H -I. -I. -I. -AA -I.. -I.. -g -c MStreamable.cpp  +Z
-DPIC -o
 .libs/MStreamable.lo
Error (future) 600: "MStreamable.cpp", line 32 # Type specifier is omitted;
"int
" is no longer assumed.
                       const MStreamable& obj)
                       ^^^^^
Error 22: "MStreamable.cpp", line 32 # Syntax error.
                       const MStreamable& obj)
                                        ^
Error 711: "MStreamable.cpp", line 31 # There is no matching declaration for
'st
d::basic_ostream<char,std::char_traits<char> > &<<()' in namespace
"namespace cg
icc".
    CGICCNS operator<<(STDNS ostream& out,
    ^^^^^^^^^^^^^^^^^^
Error 172: "MStreamable.cpp", line 34 # Undeclared variable 'obj'.
      obj.render(out);
      ^^^
Warning:        1 future errors were detected and ignored. Add a '+p' option
to
detect and fix them before they become fatal errors in a future release.
Behavio
r of this ill-formed program is not guaranteed to match that of a
well-formed pr
ogram
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

And adding those name space macros fixes the problem.
I am not able to explain why.

Bryan