[comp.sys.hp] problems building cfront 2.0

peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder) (11/10/89)

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";
}

and

#include <iostream.h>
#include <stdlib.h>

main()
{
   cout << "hello world\n";
   exit( 0 );    // <- this line makes all the difference
}

The first program does not print anything, the second program runs just
fine! I discovered this when trying to figure out why some of the demos
failed.

What is going on here? I used the debugger as best I could and found
that the initializer for the streams are called and the lshift function
does get the correct argument, calls the put function, but nothing gets
out... With the regular C debugger (xdb) I can't go any further than
that since it does not understand C++.

Also, there are a few changes that I would suggest for building this
beast on HP9000/800. Who at AT&T and HP is interested in hearing about this?
(specifically generic.h needs a change for the token pasting)

If you are an HP compiler wizard, would you get in touch with me?
There are a bunch of files which the compiler croaks on with -O2 but not
-O1. The C++ documentation from AT&T mentions this. Can something short
of handcompiling these files be done? Why does the compiler die? Do the
files need to be broken up? How about creative use of the +e[01] flags
when building cfront itself? I had a similar problem once on my own code
and `fixed' it by using the +e[01] flags.

Has anybody experienced similar problems? and found a fix????

Thanks for your help!

Peter
peter@media-lab.media.mit.edu

peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder) (11/10/89)

I just found that without the explicit call to exit() the destructors
never get called. Hence the outputstream just disappears (if I put
a flush in the main() without using exit() at least it prints, but
still does not call any destructors). Is that supposed to be so?

I have no idea where to look as to what went wrong. Any hints?

Thanks!

Peter
peter@media-lab.media.mit.edu

beshers@cs.cs.columbia.edu (Clifford Beshers) (11/10/89)

In article <995@mit-amt.MEDIA.MIT.EDU> peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder) writes:

   #include <iostream.h>

   main()
   {
      cout << "hello world\n";
   }

   and

   #include <iostream.h>
   #include <stdlib.h>

   main()
   {
      cout << "hello world\n";
      exit( 0 );    // <- this line makes all the difference
   }

   The first program does not print anything, the second program runs just
   fine! I discovered this when trying to figure out why some of the demos
   failed.

Since calling exit will call global destructors, I think it's
problem with the i/o buffer not being flushed correctly on a
normal exit.
--
-----------------------------------------------
Cliff Beshers
Columbia University Computer Science Department
beshers@cs.columbia.edu

shankar@hpclisp.HP.COM (Shankar Unni) (11/11/89)

> I just found that without the explicit call to exit() the destructors
> never get called. Hence the outputstream just disappears (if I put
> a flush in the main() without using exit() at least it prints, but
> still does not call any destructors). Is that supposed to be so?

I have answered this in comp.lang.c++.
----
Shankar.

jss@mrk.ardent.com (Jerry Schwarz (Compiler)) (11/11/89)

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