Xref: utzoo comp.lang.c++:5477 comp.sys.hp:3429
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!apple!vsi1!ubvax!ardent!mrk!jss
From: jss@mrk.ardent.com (Jerry Schwarz (Compiler))
Newsgroups: comp.lang.c++,comp.sys.hp
Subject: Re: problems building cfront 2.0
Keywords: C++,cfront2.0,HP9000/800,iostreams,static
Message-ID: <9061@ardent.UUCP>
Date: 11 Nov 89 03:17:11 GMT
References: <995@mit-amt.MEDIA.MIT.EDU>
Sender: news@ardent.UUCP
Reply-To: jss@mrk.ardent.com (Jerry Schwarz (Compiler))
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 37

In article <995@mit-amt.MEDIA.MIT.EDU> peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder) writes:
>I just got 2.0 and started to put it on my HP9000/835. I was very happy
>to see that this platform is supported now and the build went fine
>(aside from a few little things).
>
>Now however I find a rather puzzling problem.
>Consider:
>
>#include <iostream.h>
>
>main()
>{
>   cout << "hello world\n";
>}
>

The problem is almost certainly that a return from main isn't
causing the destructors to be called for file static variables.
I'm not familiar with the particular platform, but I have
seen similar problems. 

On some platforms you can just replace "exit" in the library
and things work out ok. Since an explicit call to exit
is causing cout to be flushed, this presumably doesn't work
on your platorm.  

Sometimes you have to construct alternative crt0's and then 
things get messy because there are different versions of crt0's 
for different circumstances (e.g.  profiling vs. non-profiling.)
And you have to change the CC script to use ld directly instead
of cc to do the linking.  On one system I remember exit was in crt0.o 

By the way when you have this kind of trouble it may mean that
the explicit call to exit isn't doing the right things either.
E.g it might be calling the destructors but not flushing stdout.

Jerry Schwarz