goodrum@unc.UUCP (Cloyd Goodrum) (06/24/86)
*** REPLACE THIS LINE WITH YOUR MESSAGE ***
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
jon@amdahl.UUCP (Jonathan Leech) (06/26/86)
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
sum@uiucdcsb.CS.UIUC.EDU (06/27/86)
It has been awhile since I looked at this, but I believe the problem is (was) a bug in the makefiles that prevents "munch" from being remade. I.e., constructors for static classes are not being called because the munch that the "c" distribution uses is not that same as that used in the "C++" compiler. Of course, the stdio/streams stuff has some static classes. Try remaking "munch". -- Bob USENET: {convex,ihnp4,pur-ee}!uiucdcs!sum CSNET: sum@uiuc.csnet ARPA: sum@b.cs.uiuc.edu