HDTenEightyP/NetNews huggingface dataset:
From: patc@cmcoa.UUCP
Subject: Getting fatal signal 6 from cc1plus
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 16:48:02 GMT

Hi, sorry to bother you, but I'm getting SIGIOT from cc1plus when
debugging is enabled.  I'm trying to make libg++-2.2 with gcc-2.2.2
running on an i386-sysv4 (and used that argument with configure).

This occurs with stage 1 and stage 2 compilers.  There were no compare
errors with stage 3.  I've made no modifications, everything's
straight "out of the box," directories and all.

The file it crashes on is libg++/src/LogNorm.cc.  According to Gdb
4.5's backtrace of the coredump, the last two items on the stack were
var_labelno, which turns out to be a variable (with a value of 48).
The third item is an actual function, output_mem_loc_descriptor
(rtl=0x8194e84), directly after the line that goes 

	case PLUS:
	  output_mem_loc_descriptor (XEXP (rtl, 0));

The backtrace is huge.  If you want a coredump or the backtrace or
whatever, let me know.  Not being able to debug this file is no big
deal to me, I just thought I'd let you know.  Let me know if I can do
anything to help.

Newsgroups: gnu.g++.bug
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Subject: No bug: was bug in 2.2.2 - object as function arguments ??
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Sat, 26 Sep 1992 09:26:14 GMT

Same problem as mentioned before. Since temporary objects are not
guaranteed to exist ANYTIME after their explicit use, passing of
pointers from temporary objects is illegal. This is sad because
it complicates things as in the sample, but as is shown clearly
in the ARM, only a garbage collection mechanism can be smart enough
to guarantee temps exist until all references cease. And c++
hasn't such.

Newsgroups: gnu.g++.bug
From: enewton@uunet.uu.net
Subject: wrong virtual called in MI cases
Reply-To: srg!enewton@uunet.uu.net
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 13:55:46 GMT

gcc2.2.2 configured for sco, native assembler and linker.

I get unexpected output from the program given below.  I expect the
three virtual functions called "create" to get called once.  I only
get the create for class "E".  If I move the constructor

C::C {}

around I get different results.  If I switch the definitions of D and
E around, the output changes again.

-Eric uunet.uu.net!srg!enewton

----------------------------------------------------------------------
$ gcc2 -v -xc++ testit.c
Reading specs from /usr/local/lib/gcc-lib/sco/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sco/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -DM_UNIX -DM_I386 -DM_COFF -DM_WORDSWAP -Dsco -DSCO -D__unix__ -D__i386__ -D__M_UNIX__ -D__M_I386__ -D__M_COFF__ -D__M_WORDSWAP__ -D__sco__ -D__SCO__ -D__unix -D__i386 -D__M_UNIX -D__M_I386 -D__M_COFF -D__M_WORDSWAP -D__sco -D__SCO -nostdinc -I/usr/include testit.c /usr/tmp/cca11994.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/sco/2.2.2/cc1plus /usr/tmp/cca11994.i -quiet -dumpbase testit.cc -version -o /usr/tmp/cca11994.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.1.
 as -o testit.o /usr/tmp/cca11994.s
 ld /lib/crt1.o /usr/local/lib/gcc-lib/sco/2.2.2/crtbegin.o -L/usr/local/lib/gcc-lib/sco/2.2.2 -L/usr/local/lib testit.o -lgcc -lc -lgcc /usr/local/lib/gcc-lib/sco/2.2.2/crtend.o /lib/crtn.o
$ ./a.out
E's create
E's create
E's create
----------------------------------------------------------------------
extern "C" {
   void puts(const char *);
}

class Thing
{
   int t;
 public:
   Thing() {}
   virtual ~Thing() {}
   virtual void f() {}
};

class A
{
   Thing a;
 public:
   A() {}
   virtual ~A() {}
   virtual void isValid() {}
};

class Q
{
   Thing q;
 public:
   Q() {}
   virtual ~Q() {}
   virtual void create() { puts("Q's create"); }
};

class B : public Q
{
   Thing b;
 public:
   ~B() {}
};

class C : public A, public B
{
   Thing c;
 public:
   C();
   ~C() {}
   void isValid() {}
};

class D : public C
{
   Thing d;
 public:
   D();
   ~D() {}
   void create() { puts("D's create"); }
   void isValid() {}
};

class E : public C
{
   Thing e;
 public:
   E(); 
   ~E() {}
   void create() { puts("E's create"); }
   void isValid() {}
};

D::D() { }
E::E() { }
C::C() { }

C * f()
{
   static i = 0;
   i++;
   if (i==1) return new C;
   if (i==2) return new D;
   if (i==3) return new E;
   return 0;
}

main()
{
   f()->create();
   f()->create();
   f()->create();
}



Newsgroups: gnu.g++.bug
From: fjh@munta.cs.mu.oz.au (Fergus James HENDERSON)
Subject: Re: Gnu C bug in '...' wild arg specification
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu
Date: Thu, 1 Oct 1992 07:58:37 GMT

A.APPLEYARD@fs1.mt.umist.ac.UK writes:

>After an unexpected compiler error remark in compiling a program, I compiled
>this test program with a recent version of Gnu C++, and I got this error:-
>
>t$$.cc: In function `int  main()':
>t$$.cc:7: warning: cannot pass objects of type `Complex' through `...'
>
>Why does '...' accept structs but not classes? I have found nothing in (two
>good Gnu C++ manuals that I have) about restrictions about what can be passed
>through '...'. What other restrictions are there about '...'?

You cannot pass objects with constructors or operator= through '...'
(I can't find a reference to this in C++PL 2nd Ed. right now, but Cfront 2.0
also rejects your program.)
This is a restriction in the language, not a problem with g++.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Newsgroups: gnu.g++.bug
From: A.APPLEYARD@fs1.mt.umist.ac.UK
Subject: Gnu C bug in '...' wild arg specification
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 12:08:55 GMT

typedef struct{double re,im;} complex;
class Complex{public:double re,im;
    inline void operator=(Complex&X){re=X.re; im=X.im;};};
void zxcvbnm(int n,...){n=1;}
main(){complex c; Complex C;
zxcvbnm(1,c);
zxcvbnm(1,C);}

After an unexpected compiler error remark in compiling a program, I compiled
this test program with a recent version of Gnu C++, and I got this error:-

t$$.cc: In function `int  main()':
t$$.cc:7: warning: cannot pass objects of type `Complex' through `...'

Why does '...' accept structs but not classes? I have found nothing in (two
good Gnu C++ manuals that I have) about restrictions about what can be passed
through '...'. What other restrictions are there about '...'?

Newsgroups: gnu.g++.bug
From: dak@pool.INformatik.rwth-aachen.DE (David Kastrup)
Subject: g++-2.2.2 signal 11 on illegal conversion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 13:25:56 GMT

This (admittedly erroneous) oneliner chokes g++-2.2.2 into signal 11.
operator int() { }

Newsgroups: gnu.g++.bug
From: yergeau@outpost.stanford.edu (Dan Yergeau)
Subject: g++ 2.2.2 -- class templates and const member functions
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 09:14:11 GMT

Templates do not handle const member functions properly.  Const member
functions do work in non-template classes.

This probably occurs on all machines/OS.  I've tried it on an SGI 4D
(mips-sgi-irix4) running Irix 4.0.1 and a Intel '386 (i386-sysv)
running vanilla SysV 3.2.

The sample source file is below.  The command line to show the problem
is

% g++ -DKONST=const -c bug.cc
bug.cc: In function `int  main ()':
bug.cc:12: template for method `bar' doesn't match any in class `Foo<int>'

Dropping off the -DKONST=const compiles the file successfully.

============================================================================
#ifndef KONST
#define KONST
#endif

// Demonstation purposes only.  I don't really write code like this.

template<class T> class Foo {
public:
    int bar() KONST;
private:
    int _n;
};

template<class T> int Foo<T>::bar() KONST
{
    return _n;
}

int main()
{
    // Use the template to generate the definitions for an
    // instantiation of Foo<T>
    Foo<int> f;
}
============================================================================

--
Dan Yergeau
yergeau@gloworm.Stanford.EDU


Newsgroups: gnu.g++.bug
From: marc@dumbcat.sf.CA.US (Marco S Hyman)
Subject: function typedef
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 04:20:59 GMT

The compiler indicates an error on the noted line when compiling this class:

	class X {
	  public:
	    typedef int * Y( int );	// error
	    Y * y;

	    typedef int * (*Z)( int );
	    Z z;
	};

The ARM ($7.1.3, pg 108) indicates that this is valid -- but the example is
not inside a class.  Cfront (2.0) does not complain.

// marc

g++ -v -c x.c
Reading specs from /usr/local/lib/gcc-lib/i386-sysv/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/i386-sysv/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dunix -Di386 -D__unix__ -D__i386__ -D__unix -D__i386 x.c /usr/tmp/cca11620.i
GNU CPP version 2.2.2 (80386, ATT syntax)
 /usr/local/lib/gcc-lib/i386-sysv/2.2.2/cc1plus /usr/tmp/cca11620.i -quiet -dumpbase x.cc -version -o /usr/tmp/cca11620.s
GNU C++ version 2.2.2 (80386, ATT syntax) compiled by GNU C version 2.2.2.
x.c:3: field `Y' invalidly declared function type

Compilation exited abnormally with code 1 at Sun Oct  4 21:15:04

Newsgroups: gnu.g++.bug
From: walter@mathworks.COM (Walter Gillett)
Subject: pointer to member function
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 20:12:31 GMT

Version of GNU:  GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
Platform:        SPARCstation 2, SunOS 4.1.2
Complete input file: shown below
Command args:    g++ -o ptr -g -I/home/walter/gcc/lib/sun4/g++-include -c ptr-ref.cc

The code shown below produces a seg fault; I think it should work
fine.  It compiles with no errors or warnings.  It corresponds to the
file ptr-ref.cc in the command line shown above.  The idea is that "f"
is a pointer to the member function "inc".  Member function "hawk"
dereferences the f pointer in order to call "inc".  Note that the
"this" pointer in the definition of hawk should be redundant; I added
it in order to appease ObjectCenter (formerly Saber-C++).  With that
change, the code loads and executes properly in ObjectCenter but not
in g++.  This is the first example I've found where ObjectCenter has
been more robust than g++.  I know that you folks don't have the
resources to provide support, but if you have any thoughts on this
topic I'd love to hear them.  In particular, if there is in fact a bug
here, that would be of interest.  I believe that the code below should
be legal (with or without the "this" pointer), but a lot of the
compilers I've tried don't like it very much.


#include <iostream.h>

class mouse 
{
public:
   int hawk();
   mouse::mouse();
   int mouse::inc(int x);
   int (mouse::*f)(int);
private:
};

int mouse::inc(int x)
{
   return x+1;
}    

mouse::mouse()
{
   f = &mouse::inc;
};

int mouse::hawk()
{     
   return (this->*f)(33);
};

int main()
{
   mouse m;
   cout << m.hawk();
};  

Newsgroups: gnu.g++.bug
From: solomon@cs.wisc.edu (Marvin Solomon)
Subject: bogus warning (g++ 2.2.2) (PS)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 11:43:30 GMT

P.S. That's with -Wall -pedantic.

Newsgroups: gnu.g++.bug
From: adams@cs.wisc.edu (Paul Adams)
Subject: g++ 2.2.2 crash
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 15:37:48 GMT

Hi.  Below is a program that causes g++ to crash when both -g and -O are used
(either -g or -O by itself works fine).  Also, if inlining of functions is
turned off, it works.


Paul Adams
Department of Computer Sciences
1210 W. Dayton St
Madison, Wisconsin 53706
adams@cs.wisc.edu

-------------------------------------------------------------------------------
Script started on Wed Sep 30 10:28:49 1992
adams 21>cat bug4.cc
inline void foo(int) { }
  
void bar()
{
	foo(5);
}
adams 22>g++ -c -v -g -O bug4.cc
Reading specs from /usr/gnu/lib/gcc-lib/decstation/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix -D__OPTIMIZE__ -g -D__LANGUAGE_C_PLU



S_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C bug4.cc /usr/tmp/cca12750.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cc1plus /usr/tmp/cca12750.i -mgpopt -quiet -dumpbase bug4.cc -g -O -version -o /usr/tmp/cca12750.s
GNU C++ version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C version 2.2.2.
/usr/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 11
adams 23>exit

script done on Wed Sep 30 10:29:39 1992

Newsgroups: gnu.g++.bug
From: werner@ast1.uibk.ac.at (  Werner Benger     )
Subject: (none)
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 22:05:34 GMT

 Dear Debuggers of the GNU C++ Compiler,

 There seems to be another bug in the GNU C++ 2.2.2 Compiler:
 If a constant reference is created, the value of the original variable
 is copied once to a different place where the reference points to.
 Therefore the reference value is not affected when the variable is changed.
 In the following example the output should be: 
	   19 5 7 11        instead of       19 19 19 19
 The same error occurs when "int" is changed to "double".
 While debugging, I detected also an mistake ( is it a mistake ?)
 in <iostream.h> :
            ostream&operator<<(ostream&,void*) 
  should be changed into
            ostream&operator<<(ostream&,const void*) 
  since the content of a pointer been printed out is not changed 
  ( at least it should not ).  With the current version a warning message
  is produced when compiling the program below.

 Good luck for killing these bugs,

 			Werner (werner@ast1.uibk.ac.at)



#include <iostream.h>

int x=19;

main()
{
const int&y=x;

	cout << y << " ";
	x=5;	cout << y << " ";
	x=7;	cout << y << " ";
	x=11;	cout << y << " ";
	cout << &x << "   " << &y << '\n';
	return 0;
}






Newsgroups: gnu.g++.bug
From: achilles@ira.UKa.DE (Alf-Christian Achilles)
Subject: Internal Compiler Error 116
Organization: Universitaet Karlsruhe, Karlsruhe, Deutschland.
Distribution: gnu
Date: Fri, 2 Oct 1992 15:39:49 GMT

When compiling the following small program containing a syntactical
error, I encountered an internal compiler error 116 in g++-2.2.2.
The syntactical error consists of missing parentheses around
"this->*amp" which would get the precedence right.


class A {
public: 
  typedef A (A::*AMFA)(A);
  A apply(A a, AMFA amp) {return this->*amp(a);};
};

main()
{
};

cd /home/inst/achilles/tmp/
g++ -v -o g++bug g++bug.cc -O2 -Wall -g
Reading specs from /tools/gnu/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /tools/gnu/lib/gcc-lib/sun4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ -g -Wall g++bug.cc /usr/tmp/cca21143.i
GNU CPP version 2.2.2 (sparc)
 /tools/gnu/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca21143.i -quiet -dumpbase g++bug.cc -g -O2 -Wall -version -o /usr/tmp/cca21143.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
g++bug.cc: In method `class A A::apply (class A, auto class A(class A::*)(class A))':
g++bug.cc:4: internal compiler error 116, please report

Compilation exited abnormally with code 1 at Fri Oct  2 11:31:20



Alf
--
Alf-Christian Achilles       achilles@ira.uka.de ! Mail : P.O. Box 6980
Lehrstuhl Informatik fuer Ingenieure             !        7500 Karlsruhe 1
    und Naturwissenschaftler                     ! Voice: +49 721 608-4335
University of Karlsruhe, Germany                 ! FAX  : +49 721 698675




Newsgroups: gnu.g++.bug
From: mbeaulie@tollys.UUCP (Marc Beaulieu)
Subject: g++ 2.2.2 problem with operator delete
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 16:20:52 GMT

    There seems to be a bug in g++.  It doesn't handle a class-specific
 delete operator with a size parameter.  You can declare the operator,
 but then when you try to delete an object you get a compile error.

 We are running g++ 2.2.2 on a sparc running SUN-OS 4.1.
 gcc was configure with "sun4"

 Here's an example:
 
    lammbrau 1 ~ 91) g++ -c x.c
    x.c: In function `int  main ()':
    x.c:11: too few arguments for method `operator delete'
    cp-method.c:2217: failed assertion `rval != error_mark_node'
    /usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6
 
    lammbrau 1 ~ 92) CC -c x.c
    "x.c", line 3: warning: X  has X::operator delete() but no operator new()
 
    lammbrau 0 ~ 93) cat x.c
    #include <stddef.h>
 
    class X {
    public:
       void operator delete(void*, size_t);
    };
 
    int main()
    {
       X* x = new X;
       delete x;
       return 0;
    }
 
 
 

##############################################
Marc Beaulieu                 Dept. 6s52
Bell-Northern Research, Montreal, Canada.
INTERNET:  mbeaulie@bnr.ca

Newsgroups: gnu.g++.bug
From: gswang@lonnie-mack.cs.unlv.edu (Guishen Wang)
Subject: Write and read binary file
Keywords: iostream bugs
Reply-To: gswang@lonnie-mack.cs.unlv.edu (Guishen Wang)
Organization: UNLV Computer Science and Electrical Engineering
Distribution: gnu
Date: Wed, 30 Sep 1992 05:39:05 GMT

   I am working on a project with G++. When I try to stream

a object into file, I find some member function of iostrem does

not  work correctly.

     First I wrote 2 objects into file then read them back.

Everything is wrong. I want know where this bug come from?

from my code ? or from the compiler?

     Does anybody know this problem?
      
      Please send me mail and tell me what is wrong ASAP, because I can

not  make any progress on my project before this is done.

    I appreciate your time!


    the following is the code and output:




#include <std.h>
#include <fstream.h>
#include <iostream.h>
class people{
public:
  char name[20];
  long ssn;
  people(char *n,long num){ memset (name,0,20);strcpy(name,n);}
};
int main()
{ people p0("",0);
  people p1("joe",12342);
  people p2("jery",345435);
  ofstream out("file");
  out.write((char *)&p1,sizeof(p1));
  out.write((char *)&p2,sizeof(p2));
  long pos=out.tellp();
  cout<<"position after write 2 people="<< pos<<"\n";
  out.close();

  ifstream input("file");
  input.read((char *)&p0,sizeof(p0));
  cout << "This is what is red from the file :  "<< p0.name <<" "<<p0.ssn<<"\n";
    return 0;
}



mayall% g++ -v cpptest.cc
Reading specs from /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/specs
gcc version 2.1
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/cpp -lang-c++ -v -undef -D__GNUC__=
2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix
__ -D__sparc -D__sun -D__unix cpptest.cc /usr/tmp/cc021848.i
GNU CPP version 2.1 (sparc)
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/cc1plus /usr/tmp/cc021848.i -quiet
-dumpbase cpptest.cc -version -o /usr/tmp/cc021848.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o cpptest.o /usr/tmp/cc021848.s
 /local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/ld -e start -dc -dp /lib/crt0.o -L/
local/gnu/lib/gcc/sparc-sun-sunos4.1.1/2.1/ -L/local/gnu/lib/ cpptest.o -lg++ -l
gcc -lc -lgcc
mayall% a.out
position after write 2 people=0
This is what is red from the file :  jjoe 0


    (the position should be a number greater than 0)
    (the output "jjoe 0 "should be "joe 12342")



Newsgroups: gnu.g++.bug
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Gnu C bug in '...' wild arg specification
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Distribution: gnu
Date: Thu, 1 Oct 1992 22:12:09 GMT

A.APPLEYARD@fs1.mt.umist.ac.UK writes:


>After an unexpected compiler error remark in compiling a program, I compiled
>this test program with a recent version of Gnu C++, and I got this error:-

>t$$.cc: In function `int  main()':
>t$$.cc:7: warning: cannot pass objects of type `Complex' through `...'

>Why does '...' accept structs but not classes? I have found nothing in (two
>good Gnu C++ manuals that I have) about restrictions about what can be passed
>through '...'. What other restrictions are there about '...'?

This was a warning. When passing objects through ..., as ARM explains,
data is copied RAW, that is, not constructed in any way. It would
not do to pass it initialized, because the called function would
not destruct it, or could use methods on it or whatever. So ... is
a cludge passing representations. You can do it, but the results are
far from well-defined. In the case of Complex, it might even work.

Newsgroups: gnu.g++.bug
From: sjm@merlin.anu.edu.au (Stephen Meatheringham)
Subject: I don't understand this ....
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 21:17:07 GMT

Hello,
   I am trying to install gcc and g++ (2.2.2) on our Sun Sparcstations running
SunOS4.1.2.    Everything seems to go fine - no errors or crashing out during 
the making and installation.  But ... when we try to compile a C++ program I
get the following :
sjm@moggie> g++ -c sjm.c
sjm.c:2: iostream.h: No such file or directory

Further digging around in the man page suggests there should be a directory
such as /usr/local/lib/g++-includes which contains the include files.   I'm
afraid there's no such beastie to be found, all the other include files for
gcc look okay in /usr/local/lib/gcc-lib/...

We do have the Sun supplied C++ compiler and that works fine, when you specify
-I/lusr/lang/SC1.0.1/include.   Do we have to specify the same for g++?  If so
why the discussion about g++-include in the man page?
 

				Stephen Meatheringham
				Mt. Stromlo Observatory
				Private Bag, Weston Creek P.O.
				ACT 2611, AUSTRALIA
				email : sjm@moggie.anu.edu.au


Newsgroups: gnu.g++.bug