🚀 go-pugleaf

In article <2282@unc.unc.UUCP>, goodrum@unc.UUCP (Cloyd Goodrum) writes:
>
>	I am installing AT&T's C++ release 1.0 on a Vax 11-785 running
> 4.2 BSD Unix.I have finally gotten it to compile OK, but it doesn't want to
> create runnable object code. Whenever I try to compile and run the following
> program:
>
> #include <stream.h>
>
> main()
> {
>	cout << " Hello, world \n";
> }
>
> I get a bus error and a core dump.
>
>
>	I then tried creating a regular c program from this which I compiled
> and ran through dbx. Dbx told me that the problem was with the function
>
>	_ostream__lshiftFPC__.
>
>	Has anybody out there had any similiar problems?
>
>	Cloyd Goodrum III

    Yes. This problem seems to crop up in almost every C++
installation.  Without going into great detail, there is a postfilter
called 'munch' which scans the namelist of a C++ executable looking
for global objects which require calls to constructors (and
destructors). It generates a small table which is compiled (if you
look in the CC shell script it's called '__ctdt.c') and relinked with
the executable. At runtime, the C++ startup routine goes through this
table calling the specified constructors for each static object in
the table.

    As it happens, members of class ostream (such as 'cout' in your
example) require constructors. If the 'munch' program is not
successfully run (as determined from its exit status) and the table
relinked, said constructors will not be called with the end effect
that a NULL pointer is dereferenced when you try to send output to
cout.

    I posted a long article on various C++ installation problems on
4.2 BSD and several flavors of System V some months ago which included
a fix for this. Unfortunately I don't have it online now (having moved
for the summer); perhaps someone who does could send Cloyd a copy, or
even repost it (it seems like we keep hearing problems like this
every 2 weeks in this group).  As I recall, this particular fix was
to change return() to exit() in munch:main() as the proper error code
was not getting back to the shell with return().

    Incidentally (speaking mainly to Bjarne) how about modifying CC
to print a warning when this happens explaining what the problem is,
and removing the executable?

    -- Jon Leech (...seismo!amdahl!jon)
    UTS Products, Amdahl Corporation
    __@/

This article does not represent the views of Amdahl Corporation