HDTenEightyP/NetNews huggingface dataset:
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: Re: g++ install
Date: 7 Oct 1992 04:14:13 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <9210061955.AA07659@sde.mdso.vf.ge.com> tootill@sde.mdso.vf.ge.COM (Tootill Ed) writes:
>I need expanded installation instructions for g++ compiler.

You mean, for g++-1.4x, for some x.  I would recommend against the use
of this compiler.  Some of RMS's comments seem to imply the reverse
(e.g. the 1.x version is more stable), but he's talking about the C
part.  None of the extensive effort Cygnus and others have made towards
fixing g++ has been applied to the 1.x compiler; meanwhile, entropy
has probably made it worse.  I'd suggest using 1.40.3 in preference
to later versions, og g++-1.x, since I know I made 1.40.3 work for me.

It is true that gcc-1.42 is the "maintained for stability" version.  But
it does not follow by any means that g++-1.41.x or g++-1.42.x should be
used.  Its intallation procedure is very complex, and it is also
considerably buggier than g++-2.2.2.  Don't even try virtual base classes,
for example.  Also, no templates.

g++-2.2.2 is included in gcc-2.2.2.  Simply install gcc-2.2.2 and you'll
get the C++ part as well.

>Rhetorical comment: Why is "free" synonymous with "who needs
>documentation, let them figure it out the hard way".

Because people haven't been as good about producing and giving away
documentation as they've been about giving away code.  Don't like it?
Write some!  Often a knowledgeable user is a better candidate than the
original author to write good documentation, because the programmer
"knows too much" and isn't always conscious of what the user *doesn't*
know.

But I think you'll find the installation instructions included with
gcc-2.2.2 much easier to follow.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help
From: gswang@lonnie-mack.cs.unlv.edu (Guishen Wang)
Subject: Read and write binary file
Keywords: iostream 
Reply-To: gswang@lonnie-mack.cs.unlv.edu (Guishen Wang)
Organization: UNLV Computer Science and Electrical Engineering
Date: Wed, 30 Sep 92 05:33:54 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?

     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")
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: gnu.g++.help
Subject: Re: static member
Date: 28 Sep 92 13:51:21 GMT
Reply-To: brendan@cygnus.com
Distribution: gnu
Organization: Cygnus Support, Palo Alto, CA
In-reply-to: cbt@yosemite.inesc.pt's message of 25 Sep 92 15:16:17 GMT

In article <CBT.92Sep25151617@yosemite.inesc.pt> cbt@yosemite.inesc.pt (Conceicao Batista Tavares) writes:

   I have the following program:

   #include <iostream.h>

   class xpto {
   public:
   static int c;
   int f;
   };

   main ()
   {
   xpto B;

   cout << B.c <<endl;
   }

   And when I try to compile it I get this message:

   ----
   ld:
   Undefined:
   _4xpto$c
   collect: /usr/bin/ld returned 1 exit status
   ----

You're only providing a declaration of the member; somewhere you have
to provide a definition.  (e.g., "int xpto::c = 0;")

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811
                                                 Re-elect Clinton/Gore in '96!
Newsgroups: gnu.g++.help
From: Michael.Conner <Michael.Conner@mixcom.mixcom.com>
Subject: fstream filbuf problem
Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A.
Distribution: usa
Date: Tue, 29 Sep 1992 16:00:50 GMT



I need to get an fstream with known buffer size.  I am trying
to do this by getting the filebuf through rdbuf() and then setting
the buffer, using setbuf(char *, int ).  I keep getting a bus error
when I try to actually output something. Is this the wrong way to
do this ?  If so, shouldn't rdbuf() return a const filebuf *. Is
there a work around for this?  Help!  

I'm using gcc 2.2.2 on INTERACTIVE UNIX Sys V/386 Rel 3.2

Here's the code:

#include <iostream.h>
#include <fstream.h>

main (){
   fstream x;
   (x.rdbuf())->setbuf(  new char[4096], 4096 );
   if (x.fail()) cout << "fail set(1)" << endl; 
   x.open("somefile", ios::in | ios::out );
   if (x.fail()) cout << "fail set(2)" << endl; 
   cout << "----" << endl;
   x << "some output";
   cout << "++++" << endl;
}

Here's the results:
----
Bus error - core dumped
-- 
Michael.Conner@mixcom.com
Newsgroups: gnu.g++.help
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: gcc 2 / gas 1.38.1 on Sequent Symmetry?
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Sat, 26 Sep 1992 08:21:01 GMT

Has anyone successfully gotten GAS 1.38.1 working with GCC 2.x?  The last
time I tried (around 2.0), I got code which died miserably when I tried to
use it.

--
Jason Merrill
jason@jarthur.claremont.edu
Newsgroups: gnu.g++.help,gnu.emacs.help
From: steve@jack.sns.com (J. Steven Harrison)
Subject: TAGS FIles for g++
Organization: Systems'n'Software
Date: Sat, 26 Sep 92 19:22:21 GMT

Okay I new at this....

I do I generate a TAGS for for G++. 

If I use ctags+ from USL then I get from emacs: not a valid TAG file.

Any help is appreciated.


-- 
J. Steven Harrison, PhD.	steve@jack.sns.com
45034 Imnaha Court		Voice:	(510)623-8651
Fremont, CA   94539-6669	Data:	(510)623-8652
Systems'n'Software            	FAX:	(510)623-8656
From: tom@clam.UUCP (Tom B.)
Subject: conversion and void *
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Date: Sat, 3 Oct 1992 17:42:09 GMT


Unsubscribe
From: djd@csg.cs.reading.ac.uk (David J Dawkins)
Newsgroups: gnu.g++.help
Subject: Documentation
Date: 29 Sep 92 15:54:26 GMT
Organization: University of Reading


Could someone please point me in the direction of the most up-to-date
documentation for g++ (and/or the FAQ). 

Cheers,

-dave

-- 
djd@uk.ac.reading.cs.csug
djd@uk.ac.reading.cs.csg
davidd@integ.uucp
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: gnu.g++.help
Subject: Re: compiler error: libg++2.0, g++ (gcc) 2.2.2, SunOS 4.1
Date: 28 Sep 92 13:30:49 GMT
Reply-To: brendan@cygnus.com
Organization: Cygnus Support, Palo Alto, CA
In-reply-to: dhesi@cirrus.com's message of Fri, 25 Sep 1992 19:54:47 GMT

In article <1992Sep25.195447.7992@cirrus.com> dhesi@cirrus.com (Rahul Dhesi) writes:

   I observed an internal compiler error when trying to install libg++2.0
   using g++ (gcc) 2.2.2, on a system running SunOS 4.1.  The following is
   cut-and-pasted from an 80-character wide screen.

   gcc -I. -I./../iostream -I./../g++-include  -c BitSet.cc
   gcc: Internal compiler error: program cc1plus got fatal signal 6
   *** Error code 1

This will be fixed with the next release (really soon).
--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811
                                                 Re-elect Clinton/Gore in '96!
From: jonathan@gabriel.keele.ac.uk (Jonathan Knight)
Newsgroups: gnu.g++.help
Subject: Re: gcc 2 / gas 1.38.1 on Sequent Symmetry?
Date: 26 Sep 92 13:25:56 GMT
Organization: Keele University, England

jason@jarthur.claremont.edu (Jason Merrill) writes:

>Has anyone successfully gotten GAS 1.38.1 working with GCC 2.x?  The last
>time I tried (around 2.0), I got code which died miserably when I tried to
>use it.


There is a bug in gas which causes it to fail with gcc 2.2 on 80386
processors.  The patch I got from Peter Schauer
(pes@regent.e-technik.tu-muenchen.de) fixed the problem.  Unfortunately I
no longer have the patch seperate to the gas program, however you should
probably check ftp.regent.e-technik.tu-muenchen.de in pub/gnu to see
if it is there.
Newsgroups: gnu.g++.help
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: ALPHA code generator?
Organization: Digital Equipment Corporation, Cambridge Research Lab
Date: Mon, 28 Sep 1992 17:06:41 GMT

In article <8039@public.BTR.COM>, eeh@public.BTR.COM (Eduardo E. Horvath  eeh@btr.com) writes:
> 
> Does anyone have a gcc/g++ code generator for the DEC ALPHA machines?
> 

It's under development; should be out soon.  GCC on Alpha OSF is running just
fine; don't think anyone has played with g++ as yet.  Note that the code
generated as a cross compiler will be much poorer than that generated native
(has to do with size of datatypes and what kind of optimizations gcc will then
do; Alpha OSF is a full 64 bit system), and I don't think we've tried 
it as a cross compiler since we're native. So you will need an Alpha OSF system 
for best results (or some other 64 bit system; just try to find one!).

I'll leave it to the author to comment if he desires (or not, if he doesn't
want to be pestered about it).  Otherwise, all I'll say is "Alpha support 
will be in a future release of gcc".
				- Jim Gettys
From: neve@nlm.nih.gov (Leif Neve)
Newsgroups: gnu.g++.help
Subject: Trying to build g++ on a DECstation!
Date: 28 Sep 92 14:58:22 GMT
Reply-To: neve@nlm.nih.gov
Organization: National Library of Medicine

I'm trying to build g++ 1.42.0 on a DECstation 3100 running Ultrix 4.2.
It builds fine. But when I run it, it bails out saying:

    g++: installation problem, cannot exec collect: No such file or directory

When I define COFFLAGS in the Makefile to use ECOFF, it tries to
compile collect.c and fails (doesn't understand typedef 'tree' and 'mips_sections').

(1) I'm not picky about which version of g++ to build. Is there a version
out there that works for the DECstation 3100? (At one time I downloaded
gcc 2.2.2 but shied away from it when I read that setting LANGUAGE=c++
was a "waste of time.")

(2) If I stick with 1.42.0, what exact changes should I make to the Makefile
to get it to build?

Thanks,
Leif Neve
From: neve@nlm.nih.gov (Leif Neve)
Newsgroups: gnu.g++.help
Subject: Re: Trying to build g++ on a DECstation!
Date: 28 Sep 92 17:58:46 GMT
Reply-To: neve@nlm.nih.gov
Organization: National Library of Medicine

>In article <1992Sep28.150027.25539@nlm.nih.gov>, neve@nlm.nih.gov (Leif Neve) writes:
>
>|>(1) I'm not picky about which version of g++ to build. Is there a version
>|>out there that works for the DECstation 3100? (At one time I downloaded
>|>gcc 2.2.2 but shied away from it when I read that setting LANGUAGE=c++
>|>was a "waste of time.")

Oops! Thanks to all you kind souls out there that showed me the error of my
ways. I mistook the context of the "waste of time" allusion.

I'm rolling up my sleeves even as I speak to build gcc 2.2.2 on my DECstation.

Thanks, again.
Leif Neve
Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: bug in gen-params.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 04:06:04 GMT

Problem 1 may be a problem with usng the wrong compiler.  Try make CC=gcc.

> Solution 2) This was HP's fault.  I had to change stdlib.h and math.h.

Yes.  Ideally, gcc should have a fixincludes patch for this.

>  For what it's worth: The HP man pages said that new applications
> should use memcmp, memmove and memset instead of bcmp, bcopy and
> bzero.

I think libg++ has been more-or-less converted at this point.

Problem 4 is a well-known problem (with the fix posted to bug-lib-g++
multiple times).

Thanks for your note.  Verison 2.3 should be out in a few weeks.

	--Per Bothner
Cygnus Support     bothner@cygnus.com


Newsgroups: gnu.g++.lib.bug
From: jbuck@forney.berkeley.edu (Joe Buck)
Subject: Re: ofstream bug in 2.1
Organization: U. C. Berkeley
Distribution: gnu
Date: Thu, 1 Oct 1992 00:37:33 GMT

In article <1aa7sjINN2rj@agate.berkeley.edu> faustus@ygdrasil.cs.berkeley.edu (Wayne A. Christopher) writes:
>The following program causes an assertion failure in the ofstream
>code.  I can't see what is wrong...  Any ideas?  I don't have 2.2 yet
>so I haven't tested it there.

The crash also occurs with libg++ 2.2.

>#include <fstream.h>
>
>static ofstream ofile;
>
>main()
>{
>    ofile = ofstream("outputfile");    
>    ofile << "Here is some output\n";
>}

Since there is no assignment operator for class ofstream, or for any of
its baseclasses, the assignment of ofstream("outputfile") does a
memberwise copy of fields to ofile.  Since the right-side ojbect is a
temporary object, it is then destroyed, leaving ofile's members pointing
to garbage.  It is then only a matter of time until the program blows up.
Assigning one ofstream to another is not valid.

The iostream library provided with cfront 2.1 handles this by making
ios::operator= a private member, which makes assignment of iostream
objects a compile-time error (except for classes like
{i,o,io}stream_withassign, which provide an assignment operator).
I think that libg++ should either do the same, or provide a correct
assignment operator.  Same for the copy constructor.

libg++ does not provide the iostream_withassign classes.  Should it?
I don't know.

You can probably get the effect you wanted by saying

	ofile.open("outputfile");





--
Joe Buck	jbuck@ohm.berkeley.edu

Newsgroups: gnu.g++.lib.bug
From: joe%joe@csesbg.co.at (Josef Leherbauer)
Subject: libg++-2.2/libg++/util/gen-params
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 14:40:48 GMT

Hi !

When I was compiling libg++ on a HP720 I found a small bug
in "libg++-2.2/libg++/util/gen-params".

Line 78

    echo "#define ${macro_prefix} ${DOLLAR_IN_LABEL}  
${DOLLAR_IN_LABEL}"

should look like this:

    echo "#define ${macro_prefix}DOLLAR_IN_LABEL  
${DOLLAR_IN_LABEL}"


Best regards,
--joe

--------------------------------------------------------------
Josef Leherbauer                        Phone: ++43-662-457915
takeFive Software GesmbH                Email: joe@csesbg.at
Jakob-Haringer-Str. 8
A-5020 Salzburg
Austria
--------------------------------------------------------------

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: g++ and glibc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 08:10:08 GMT

> Has anybody managed to get a 'pure' GNU-based system (i.e.
> using glibc-1.05 for all C-functions, and libg++-2.1 for
> other stuff)? I've tried to combine both, but its really
> a nasty thing, since both libs contain at least partially
> the same functions with different prototypes!

If the libc header files contan 'extern "C"' declarations as needed,
you can hack libg++/configure.in so that the generated
host_makefile_frag contains:
	HAVE_CPLUS_EXTERN = 1
	WRAP_C_INCLUDES =

That way, you won't use the include files in libg++/g++-include.

In your C header files do *not* contain the needed 'extern "C"'
declarations, you can use a shell-script to "fix" them.
libg++-2.3 will hopefully have some support for this.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: faustus@ygdrasil.cs.berkeley.edu (Wayne A. Christopher)
Subject: ofstream bug in 2.1
Organization: University of California, Berkeley
Distribution: gnu
Date: Tue, 29 Sep 1992 18:39:15 GMT

The following program causes an assertion failure in the ofstream
code.  I can't see what is wrong...  Any ideas?  I don't have 2.2 yet
so I haven't tested it there.

foo.cc:

#include <fstream.h>

static ofstream ofile;

main()
{
    ofile = ofstream("outputfile");    
    ofile << "Here is some output\n";
}

What happens:

% gcc-2.2.2 foo.cc -lg++-2_1
% gdb a.out
(gdb) run

Program received signal 6, Abort
0xf775f458 in kill ()
(gdb) where
#0  0xf775f458 in kill ()
#1  0xf77776fc in abort ()
#2  0xb93c in __overflow (sb=0x16650, c=72) at streambuf.C:186
#3  0xba4c in streambuf::sputn (this=0x16650, s=0x22a1 "ere is some output\n", 
    n=20) at streambuf.C:211
#4  0x5aa0 in operator<< (stream=@0x145b0, s=0x22a0 "Here is some output\n")
    at iostream.C:525
#5  0x2358 in main ()

Newsgroups: gnu.g++.lib.bug
From: bashford@mpi-dortmund.mpg.DE (D.Bashford)
Subject: Installation on a Convex
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 00:00:31 GMT

I've spent several days trying to build libg++-2.2 on a Convex using
gcc-2.2.2.  I've had a number of compile problems, mostly to do with
clashes between system header files and gnu header files, and fixed
things by hand in an ad hoc way until it compiles.  But now it flunks
the tFile-regular test by very wrong I/O of floating point types.
dtoa.C was one of the files I had trouble with in the compile.

If it matters I'll make a proper bug report; but first I wonder if
I've been barking up a well-known wrong tree.  For example, should
I be using glibc?  Is the Convex hopeless?  Is the Convex terra
incongnita for libg++ folks?

To answer a few anticipated questions, yes gcc passed the stage2
vs stage3 compare, yes I ran fixincludes, yes I am using the latest
gnu-make, no I'm not using glibc, gnu-ld, or gas.

For the next month (till I get back home to scripps.edu) I can't read
UseNet, so please reply by email to bashford@mpi-dortmund.mpg.de and
I'll summarize to this list.

Thanks,
Don Bashford

Newsgroups: gnu.g++.lib.bug
From: bill@tarduk.UUCP (William Hails)
Subject: bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 13:17:43 GMT

As you request, here's a report of what appears to be a bug in the
libg++-2.0 iostream library. We've installed the library on both sun386
(SunOs 4.02) and Interactive (i386 SysV 3.2) and get the same result:

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

main(int argc, char *argv[])
{
    char buf[512];

    while (cin >> buf)
	cout << buf << "\n";

    exit(0);
}

appears to work initially but then core dumps after what seems to be
about 1K or so of output.  Our gdb is limping but did enough to locate
the problem:

streambuf::sputc(int c) calling filebuf::overflow(int c) calling
streambuf::sputc(int c) calling filebuf::overflow(int c) calling ...

until it runs out of stack.

It doesn't seem to be an installation problem because as I say we see
the same behaviour on two distinct systems.

Any assistance would be greatly appreciated.

Cheers

       _
      / )   /) /)
     /_/ o // //
    /_)_(_(/_(/_


Newsgroups: gnu.g++.lib.bug
From: rose@t524i5.telematik.informatik.uni-karlsruhe.de (Ortwin Rose)
Subject: Unresolved External: _pctype ?
Organization: /usr/users/rose/.organization
Distribution: gnu
Date: Wed, 30 Sep 1992 22:37:16 GMT

Hi,

I have some problems when linking with libg++ (I actually
try to use glibc-1.05 with g++). I always get an unresolved
external named '_pctype', that is referenced by several
modules in libg++. Does anybody know what the hell this
name stands for, and in which module it is contained in
(i.e. what must I link to resolve this external)?

Any help is appreciated.


Best regards

-- O. Rose
   University of Karlsruhe
   Institute of Telematics

   rose@telematik.informatik.uni-karlsruhe.de


Newsgroups: gnu.g++.lib.bug
From: ro@techfak.uni-bielefeld.DE (Rainer Orth)
Subject: libg++ 2.2 on Solaris 2.0 with gcc 2.2.2 ss-920925
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 11:05:36 GMT

Recently I tried to build libg++ 2.2 on a SPARCstation ELC running Solaris 2.0
with gcc 2.2.2 ss-920925.  When doing so, I ran into a few problems, mainly
with the includes:

* libg++/g++-include/sys/socket.h declares

	int getsockopt (int, int, int, void *, int *)
	int recv (int, void *, int, int)

  but <sys/socket.h> has

	int getsockopt (int, int, int, char *, int *)
	int recv (int, char *, int, int)

* libg++/g++-include/unistd.h has

	int vhangup (void)

  contrary to <unistd.h>

	void vhangup(void)

The following diffs fix those inconsistencies:

===================================================================
RCS file: libg++/g++-include/sys/RCS/socket.h,v
retrieving revision 1.1
diff -u -r1.1 libg++/g++-include/sys/socket.h
--- libg++/g++-include/sys/socket.h	1992/06/18 01:41:56	1.1
+++ libg++/g++-include/sys/socket.h	1992/09/30 19:49:05
@@ -26,10 +26,10 @@
 int       connect _G_ARGS((int, struct sockaddr*, int));
 int       getsockname _G_ARGS((int, struct sockaddr*, int*));
 int       getpeername _G_ARGS((int, struct sockaddr*, int*));
-int       getsockopt(int, int, int, void*, int*);
+int       getsockopt _G_ARGS((int, int, int, void*, int*));
 int       listen(int, int);
 int       rcmd _G_ARGS((char**, int, const char*, const char*, const char*, int*));
-int       recv(int, void*, int, int);
+int       recv _G_ARGS((int, void*, int, int));
 int       recvfrom _G_ARGS((int, void*, int, int, void*, int *));
 int       recvmsg(int, struct msghdr*, int);
 int       rexec(char**, int, const char*, const char*, const char*, int*);
===================================================================
RCS file: libg++/g++-include/RCS/unistd.h,v
retrieving revision 1.1
diff -u -r1.1 libg++/g++-include/unistd.h
--- libg++/g++-include/unistd.h	1992/06/20 06:13:42	1.1
+++ libg++/g++-include/unistd.h	1992/09/30 19:11:56
@@ -135,7 +135,7 @@
 extern int      unlink _G_ARGS((const char*));
 extern _G_pid_t vfork _G_ARGS((void));
 extern int      vadvise _G_ARGS((int));
-extern int      vhangup _G_ARGS((void));
+//extern int      vhangup _G_ARGS((void)); /* commented out for now; wrong for Solaris 2.0 */
 extern _G_off_t lseek _G_ARGS((int, long, int));
 extern _G_ssize_t read _G_ARGS((int, void*, _G_size_t));
 extern _G_ssize_t write _G_ARGS((int, const void*, _G_size_t));

The library cannot currently be built with gcc -g since the compiler
produces invalid debugging info in some cases.  gcc gets a segmentation
violation when compiling libg++/src/{Integer, Rational, Complex, Fix,
CursesW}.cc, both with and without -O.  Worst of all,
libg++/test-install/foo_main aborts with an assertion failure since the
constructors and destructors aren't called, but this problem can be solved
easily.  I've already reported these bugs to bug-g++. 

-----------------------------------------------------------------------------
Rainer Orth, Technical Computer Science, University of Bielefeld

Internet: ro@TechFak.Uni-Bielefeld.DE



Newsgroups: gnu.g++.lib.bug