HDTenEightyP/NetNews huggingface dataset:
From: twpierce@amhux1.amherst.edu (Tim Pierce)
Subject: problem compiling libg++-2.2: gcc not specified!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 08:14:27 GMT

I'm attempting to compile libg++-2.2 with GCC 2.2.2.  However, when the
libg++ Makefile attempts to run utils/gen-params, something is telling
it to use cc rather than gcc, and when it attempts to compile dummy.C,
cc barfs on it (naturally).  Unfortunately, I'm too confused from
attempting to navigate the Makefile tree to figure out what the source
of the problem is here.  It seems that the top-level Makefile, when it
calls the libg++ Makefile, sets the CC variable to vanilla CC, but
the libg++ Makefile sets it back to GCC; perhaps the other definition
is overriding the first?

Has anyone else been having a problem that sounds like this one, or
am I just becoming prematurely senile?

--
____ Tim Pierce                / "You mean there are TWO of you, Pierce?
\  / twpierce@amherst.edu      /  God help us all."
 \/ (BITnet: TWPIERCE@AMHERST) /   -- Major Charles Emerson Winchester III

Newsgroups: gnu.g++.lib.bug
From: niemira@karloff.fstrf.org (niemira.jim)
Subject: oops
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 13:09:58 GMT

Re my last message, please send replies to niemira@karloff.fstrf.org, not
niemira@rooney.fstrf.org ( they will bounce).

|  . . ) /   | It breathes fire. -more-  | Jim Niemira
| (_(_/  |   | It breathes fire. -more-  | Senior SysOp, Frontier Sci
|    (   '   | You are not happy. -more- | niemira@karloff.fstrf.org

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ Installation Problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 06:52:50 GMT

> IMHO, and from my very limited experience with the package (vers 2.0),
> "configure" works only on SunOs and other very-BSD UNIXes.

Not true.  We and others have successfully run configure (the Cygnus
sh script shipped with gdb and libg++) on a number of different SYSV
systems.  If it doesn't work on your (Unix or Posix) system, please
let us know why.

> The system can be configured by hand

No doubt, but you shouldn't have to.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: a.shepherd@xtel.co.uk (Alan Shepherd)
Subject: Memory leak in libg++2.1 and 2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 13:31:33 GMT

I think I have discovered a memory leak in libg++ in that the
strstreambuf class allocated as part of istrstream's constructor is
not deleted.  istream::istream sets _flags to include dont_close and
this means that _strbuf isn't deleted by ~istream and istrstream
doesn't appear to have a destructor.  

Is this what you would expect ?  I have a program which uses
istrstreams and there is quite a large memory leak associated with its
use.

Alan Shepherd


---------
Alan Shepherd, X-Tel Services Ltd., University Park, Nottingham NG7 2RD.
Email: a.shepherd@xtel.co.uk, Phone: +44 (0) 602 412648 (Fax:790278)
X.400: C=GB;ADMD= ;PRMD=X-Tel Services;O=X-Tel;S=Shepherd;G=Alan


Newsgroups: gnu.g++.lib.bug
From: 75030.631@compuserve.COM (gail slemon, expersoft)
Subject: iostream handling of NULL char*
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 19:51:52 GMT

Hi!
     Our application died when trying to write a NULL char *
using the ostream << operator.  Since this code has survived
compilation using several cfront based compilers, I ended up
adding a check for NULL to ostream& operator<< (ostream& stream,
const char *s) in iostream.C.  Is this uncool?

	Thanks!
	Gail


Newsgroups: gnu.g++.lib.bug
From: atownley@mcs213k.cs.umr.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 22:42:55 GMT

I don't know if this has already come up or not, but I just
installed gcc-2.2.2 and libg++-2.2 today and was trying to
get a project I'm working on to run properly.  When I 
compiled with the new compiler, I get a bus error with the 
following function.  It didn't do this before and I was
wondering if there was something that I didn't know about.

My system configuration is a NeXTcube with NeXTSTEP 2.1
Extended and a 68040 processor.

here is the offending code, taken directly from the module:

void Chapter::WriteChapter()
/* This function writes the chapter database out to the disk in a 
 * binary format so the database maintains its integrity.
 */
{
	FILE *fp;
	char *fileName;
	char *extension = ".tbf";
 		
	cout << "\nEnter the name of the file to save the database under:  ";
	cin >> fileName;
	fileName = strcat(fileName, extension);

	fp = fopen(fileName, "w+b");
	fwrite(&Members, sizeof(Members), 1, fp);
	close(fp);
}

All I am trying to do is get a file extension tacked onto 
the end of the string.  Any ideas?

Thanks,

Andrew S. Townley
atownley@cs.umr.edu

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ 2.2 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 11:21:14 GMT

> I built libg++ version 2.2 on a HP 9000/730 (running HP-UX 8.05)
> using GCC version 2.2.2.  Whenever I try to link libg++.a with
> any C++ program, no matter how trivial, I always get the following
> error from the linker:
> 
> ld: Unsatisfied symbols:
>    _vt.filebuf (data)

Try this patch to libg++/utils/gen-params.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

===================================================================
RCS file: /rel/cvsfiles/devo/libg++/utils/gen-params,v
retrieving revision 1.15
diff -c -r1.15 gen-params
*** 1.15	1992/06/26 19:29:41
--- gen-params	1992/07/16 22:03:20
***************
*** 75,81 ****
    fi
  
    if test -n "${DOLLAR_IN_LABEL}" ; then
!     echo "#define ${macro_prefix} ${DOLLAR_IN_LABEL} ${DOLLAR_IN_LABEL}"
    elif test "`${CONFIG_NM} dummy.o | grep 'vt[$$]filebuf'`" != ""; then
      echo "#define ${macro_prefix}DOLLAR_IN_LABEL 1"
    elif test "`${CONFIG_NM} dummy.o | grep 'vt[.]filebuf'`" != ""; then
--- 75,81 ----
    fi
  
    if test -n "${DOLLAR_IN_LABEL}" ; then
!     echo "#define ${macro_prefix}DOLLAR_IN_LABEL ${DOLLAR_IN_LABEL}"
    elif test "`${CONFIG_NM} dummy.o | grep 'vt[$$]filebuf'`" != ""; then
      echo "#define ${macro_prefix}DOLLAR_IN_LABEL 1"
    elif test "`${CONFIG_NM} dummy.o | grep 'vt[.]filebuf'`" != ""; then

Newsgroups: gnu.g++.lib.bug
From: gas@spitfire.xtel.co.uk (Alan Shepherd)
Subject: assembler symbols in .o's
Organization: X-Tel Services Ltd.
Distribution: gnu
Date: Tue, 21 Jul 1992 09:16:39 GMT

I've sent two previous articles to this group and not seen them
locally.  Has anyone else seen them ?

I've done some more investigation on the problem with assembler
symnbols appearing .o files.  It seems to be that the problem arises
with gcc-2.2 when using in the -g flag.  Not all files are affected,
but sbufvform.o in the libg++ distribution is !

Alan Shepherd

Newsgroups: gnu.g++.lib.bug
From: terryh@unixhub.slac.stanford.edu (Terry Hung)
Subject: libg++-2.2 on NeXT
Keywords: libg++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 17:25:18 GMT

We had problem building libg++-2.2 with gcc-2.2.2 on NeXT. I typed 
"make all CC=gcc", and got:

  gcc -g -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c procbuf.C
  In method `int  procbuf::sys_close ()':
  incompatible pointer types for argument 0 of `int  wait (union wait*)'

We ported libg++-2.0 to RS6000, Sun4, and Ultrix-mips a few weeks ago
without any trouble, but kept having problem with NeXT. Does anyone have some
clue?
-- 
Terry Hung
Stanford Linear Accelerator Center

terryh@unixhub.slac.stanford.edu

Newsgroups: gnu.g++.lib.bug
From: uwe@bio131.uni-bielefeld.de (Uwe Mueller)
Subject: libg++-2.2 on  an NeXT, linker error
Organization: Universitaet Bielefeld
Distribution: gnu
Date: Wed, 29 Jul 1992 11:30:11 GMT

When trying to compile libg++-2.2 using gcc Version 2.1 on a NEXT  
everything works fine, until the following linker error occurs:

------------------------------------------------------------------------

gcc -o gperf new.o options.o iterator.o main.o gen-perf.o key-list.o  
list-node.o hash-table.o bool-array.o read-line.o std-err.o version.o   
./../libg++.a
ld: options.o symbol 37 (___DTOR_LIST__) has unknown n_type field (0x16)
collect: /bin/ld returned 1 exit status
*** Exit 1
Stop.

-------------------------------------------------------------------------

has anyone any Idea what goes wrong? There is a new ld located in  
/usr/local/lib/gcc-lib/next/2.0/ which is part of the release of 2.1 of  
gcc. However, the makefile uses the old ld in /bin. Attempts  
to replace the old linker by the new one led to fatal system crashes ...

Thanks for any help

uwe@bio128.uni-bielefeld.de


Newsgroups: gnu.g++.lib.bug
From: jimu@orthanc.cs.su.oz.au (James Uther)
Subject: libg++-2.2 on MIPS?
Reply-To: jimu@orthanc.cs.su.oz.au (James Uther)
Organization: sydney university
Distribution: gnu
Date: Wed, 29 Jul 1992 03:20:19 GMT

I'm trying to port something written on a sun4 to this here mips, and have
struck a wall. I have used some of libg++, so i need to compile at least
parts of the lib, however I get the following messages:

	=> ./configure mips-mips-sysv
	Created "Makefile" in /u/pgrad/jimu/src/gnu/libg++-2.2 using "config/mh-sysv"
	=> make
	sh: prefix=/usr/local: not found: No such file or directory
	*** Error code 1

	Stop.

Any ideas? Thanks
	james
	jimu@cs.su.oz.au

Newsgroups: gnu.g++.lib.bug
From: terryh@unixhub.slac.stanford.edu
Subject: make check on NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 20:49:11 GMT

With the new procbuf.C I can compile and link libg++-2.2 on NeXT
nicely now. After installed libg++-2.2, I ran the 'make check' and got:

  Entering directory '/src/libg++-2.2/next/libg++/tests'
  rm -f *.out
  gcc  tString.o -o tString ../libg++.a
  ld: multiple definitions of symbol _strtod
     ../libg++.a(dtoa.o) definition of _strtod in section (__TEXT,__text)
     /lib/libsys_s.a(strtod.o) definition of absolute _strtod (value0x5003068)
  collect: /bin/ld returned 1 exit status


Newsgroups: gnu.g++.lib.bug
From: jkh@sparc3.UUCP (Jordan K Hubbard)
Subject: Failure to compile libg++-2.1 on SPARCstation + Solaris 1.0
Organization: Lotus Ireland
Distribution: gnu
Date: Mon, 20 Jul 1992 21:41:29 GMT

gcc -g -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c  editbuf.C
editbuf.C: In method `struct edit_buffer* edit_mark::buffer ()':
editbuf.C:637: warning: implicit declaration of function `offsetof'
editbuf.C:637: parse error before `)'
editbuf.C:638: warning: control reaches end of non-void function
make[2]: *** [editbuf.o] Error 1
make[1]: *** [in-io] Error 1
make: *** [all-libg++] Error 1

Newsgroups: gnu.g++.lib.bug
From: niemira@karloff.fstrf.org (niemira.jim)
Subject: libg++ on DECstation 5000/2[04]0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 09:40:30 GMT

	Possible bug in configuration sequence for DECstation 5000/200 running
Ultrix4.2A for lib-g++-2.2 compiled with g++-2.2.2:
	src/timer.cc loses with an 'HZ undefined' error; at first I just changed
the '#if 1' to '#if 0' at the top of timer.cc to compile it the first time,
but then tests/tStack.cc gave a 'start_timer__Fv undefined' (and a few
others, I can't remember).
	I reset _G_HAVE_SYS_RESOURCE from 0 to 1 in _G_config.h to get
src/timer.cc to compile correctly, remade libg++.a, and all appears well
- all the tests have (at first glance) run correctly, although tCurses looks
a tad buggy - with DEC's curses, no wonder.
	Will keep you updated on this version/machine combo.

|  . . ) /   | It breathes fire. -more-  | Jim Niemira
| (_(_/  |   | It breathes fire. -more-  | Senior SysOp, Frontier Sci
|    (   '   | You are not happy. -more- | niemira@karloff.fstrf.org

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: losing compile on DEC5000 w/ g++2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 07:19:03 GMT

> I have traced this to the macro expansion of va_arg in /usr/include/stdarg.h,
> which looks like this:

You've installed gcc wrong.
gcc/g++ should not be using /usr/include/stdarg.h.  You should use the
GNU version of stdarg.h (whose source is gcc/gstdarg.h and gcc/va-*.h).
This is supposed to be installed by the gcc install procedure in a place
where gcc can fnd it.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: "input stack limit exceeded" causes?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 22:35:59 GMT

   What sorts of things cause groff to emit "input stack limit exceeded"
   messages?

Things like:

   .de x
   .x
   ..
   .x

You can change the input stack limit by setting the `slimit' number
register.  See gtroff(1).

James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug
From: edgar@coco.ms.washington.edu (Edgar Karl Nielsen)
Subject: another groff1.05 and gcc2.2.2 problem
Organization: Univ of Wash , Math Sciences Computing Center
Distribution: gnu
Date: Mon, 27 Jul 1992 21:27:08 GMT

I'm trying to compile groff1.05 with the new gcc2.2.2 and I'm having
problems. The patch given for lib/errarg.c worked, but I'm unable to
compile 'tbl'. Here is the error message:

Making all in tbl
gcc -c -I../lib -xc++   -O    -DHAVE_VFORK -DHAVE_SYS_SIGLIST  -DHAVE_RENAME
 -DHAVE_PID_T -DWAIT_COREDUMP_0200    main.c
gcc: Internal compiler error: program cc1plus got fatal signal 11
make[1]: *** [main.o] Error 1
make: *** [tbl] Error 1

Signal 11 is a segmentation violation!
My system is DECstation 5500/200 running ultrix4.2. I recently installed
gcc2.2.2 and groff is the only thing I use that uses g++ so it is conceivable
that there is something wrong with my gcc2.2.2 installation. Any help
would be appreciated....
-- 

All opinions are my own....
---------
Edgar Nielsen

Newsgroups: gnu.groff.bug
From: bin@primate.wisc.EDU (Brain in Neutral)
Subject: "input stack limit exceeded" causes?
Organization: Cafe Limbo
Distribution: gnu
Date: Wed, 29 Jul 1992 17:33:31 GMT

What sorts of things cause groff to emit "input stack limit exceeded"
messages?
From: jorgnsn@qucis.queensu.ca (John Jorgensen)
Newsgroups: gnu.groff.bug
Subject: gtbl not resetting line numbers
Keywords: gtbl line number
Date: 23 Jul 92 19:42:09 GMT
Distribution: gnu
Organization: Computing & Information Science, Queen's University at Kingston

This is probably more of a question than a bug report.

While trying to figure out why I was receiving error messages 
with line numbers that were 3 too high, I noticed something
I don't understand in gtbl (version 1.04, though I've looked at the code
for 1.05 and I don't think this has changed).  If I type "gtbl < /dev/null" 
or "gtbl - < /dev/null" I get the output:

    .if !\n(.g .ab GNU tbl requires GNU troff.
    .if !dTS .ds TS
    .if !dTE .ds TE

which seem to be the three extra lines.  If I type "gtbl -v - < /dev/null",
I get:

    .if !\n(.g .ab GNU tbl requires GNU troff.
    .if !dTS .ds TS
    .if !dTE .ds TE
    .lf 1 -

which includes the .lf request to reset the line number.  The last
test was suggested by looking at the gtbl 1.05 code, which suggests that
the .lf request is added if there is a named input file on the command line,
or if there is a "-" on the command line and it is NOT the first argument 
(perhaps the motivation here is an assumption that if "-" is not the
first argument, then it is preceded by named input files, and
you need the .lf requests to identify the different sources of input).

So my question is, does anyone know the rationale for not resetting the
line number when you believe you're reading only standard input?
-- 

John Jorgensen		jorgnsn@qucis.queensu.ca	(613) 545 6784
Systems Programmer, Dept. of Computing Science, Queen's University
Newsgroups: gnu.groff.bug
From: west@symcom.math.uiuc.edu (Douglas West)
Subject: output format in grefer
Keywords: grefer
Organization: University of Illinois at Urbana
Distribution: gnu
Date: Mon, 27 Jul 1992 22:03:58 GMT

In what file can we find the format in which grefer prints out a bibliography
entry, and, more to the point, how can we modify the format of the output?
I.e., is there an option we can give so that the format will be found in a
file we name?  And, where can we find instructions on how to build that file?
We have pored over the man page for grefer, to no avail.
We apologize for our ignorance, since this is a "bug" group, not a "help" 
group, but we also don't know of a "help" group for groff.

Newsgroups: gnu.groff.bug
From: leisner@trianguli.wrc.xerox.COM (Marty Leisner 311/? x?)
Subject: groff 1.05 with gcc 2.2.2 problem?
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 24 Jul 1992 17:02:06 GMT

I finally installed gcc 2.2.2 and groff is the only c++ program I use...
So I went to remake (after I installed libg++ 2.2.

I got:
leisner@trianguli$ make
Testing your C++ compiler
g++ -c -Ilib   -g -O    -DHAVE_VFORK  -DHAVE_MMAP -DHAVE_RENAME    -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H  c++test.c
g++  -g  -o c++test c++test.o 
/c++test >c++test.out
cmp -s c++test.out c++test.ref
touch c++tested
Making all in lib
gcc -g  -O  -DBSD -DSUNOS_LOCALTIME_BUG -c malloc.c
g++ -c -I. -g -O    -DHAVE_VFORK  -DHAVE_MMAP -DHAVE_RENAME    -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H  new.c
new.c: In function `void * __builtin_new (int)':
new.c:47: warning: control reaches end of non-void function
gcc -g  -O  -c itoa.c
gcc -g  -O  -c strerror.c
g++ -c -I. -g -O    -DHAVE_VFORK  -DHAVE_MMAP -DHAVE_RENAME    -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H  error.c
g++ -c -I. -g -O    -DHAVE_VFORK  -DHAVE_MMAP -DHAVE_RENAME    -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H  errarg.c
errarg.c: In method `errarg::errarg (const char *)':
errarg.c:26: assignment between incompatible pointer types
make[1]: *** [errarg.o] Error 1
make: *** [lib] Error 1


What's wrong?

--
marty
leisner.henr801c@xerox.com  
Member of the League for Programming Freedom

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: groff to LJ output
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 08:48:15 GMT

   How can I use a combination of psroff, groff to
   generate LJ output for ditroff file ? 

Yes.  The current version of psroff (3.0 patchlevel 11) comes with
instructions on how to do this.

James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug
From: anna@cis.njit.edu (anna)
Subject: groff to LJ output
Organization: New Jersey Institute of Technology
Distribution: gnu
Date: Wed, 22 Jul 1992 14:58:10 GMT

How can I use a combination of psroff, groff to
generate LJ output for ditroff file ? 

thanx

anna

Newsgroups: gnu.groff.bug
From: hargrove@ramirez.mitre.org (Paul H. Hargrove)
Subject: /undefined from -Tps output
Keywords: grops /undefined
Organization: Mitre Corporation, McLean, VA
Distribution: gnu
Date: Mon, 20 Jul 1992 17:24:11 GMT

In the version of groff I have when I format a manual page with
	groff -Tps -man file.1 >file.ps
the output file will have a line that starts something like:
	grops begin/DEFS blah blah blah..
which comes right after the contents of /usr/lib/groff/fonts/devps/prologue.
When ghostscript reads the file I get a /undefined error when it hits 'grops',
since nowhere has it be defined.  My current work around is to add the
following line to the end of the prologue file:
	/grops 1 dict def %ghostscript expands full dictionaries automagically
But this certainly should have been there, or somewhere else all ready.

I don't know what version of groff or grops I have, but I know they came
from different archives.  (the contents of prologue came with grops)  I know
that I should get the newest version of the groff distribution from prep, but
I don't really want to grab the entire mess at 2400 baud if my fix is
sufficent/correct, but I'am afraid there may be other problems if I don't.

Is there something I'm missing from my installation?
Is this a know bug that I've correctly fixed?
Or, am I just an idiot for not getting groff and grops from the same
distribution, and just reallizing that phone bills are part of the
cost of free software.
--------
Paul H. Hargrove, speaking for myself.

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: gpic and text
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 15:18:51 GMT

   I have been having great difficulty using the compass
   points associated with gpic objects (version 1.05 though I
   had the same problems with 1.03).

   I would have thought that the following input would draw
   "foo" inside the box rather than to the left of it.

	   .PS
	   scale = 25.4
	   T: "foo" width 5 height 3
	   box from T.ne to T.sw
	   .PE

gpic, like Unix pic, silently ignores irrelevant attributes (perhaps
this should be changed).  The `from' and `to' attributes are ignored
for the `box' primitive.

   And why does the following draw a right angle rather than a 'T' ?

	   .PS
	   line down
	   line right with .c at last line.n
	   .PE

The `with' attribute is ignored for the `line' primitive.

   PS.  I am using a Sun Sparc running SunOS 4.1.2 and compiled groff
   with Sun's CC 2.1.  This required changing three files because
   of complaints about type mismatches.  Here are the diffs:

This is discussed in the PROBLEMS file.

James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: another groff1.05 and gcc2.2.2 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 00:52:54 GMT

   I'm trying to compile groff1.05 with the new gcc2.2.2 and I'm having
   problems. The patch given for lib/errarg.c worked, but I'm unable to
   compile 'tbl'. Here is the error message:

   Making all in tbl
   gcc -c -I../lib -xc++   -O    -DHAVE_VFORK -DHAVE_SYS_SIGLIST  -DHAVE_RENAME
    -DHAVE_PID_T -DWAIT_COREDUMP_0200    main.c
   gcc: Internal compiler error: program cc1plus got fatal signal 11
   make[1]: *** [main.o] Error 1
   make: *** [tbl] Error 1

   Signal 11 is a segmentation violation!
   My system is DECstation 5500/200 running ultrix4.2.

On a DECstation with gcc 2.2.2 you'll need to compile the two files in
tbl without -O.

James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug
From: jars@milton.u.washington.edu (Juan Rodriguez-Sero)
Subject: groff for MS-DOS
Summary: Has anybody built froff for MS-DOS?
Keywords: groff, MS-DOS
Organization: University of Washington, Seattle
Distribution: gnu
Date: Wed, 29 Jul 1992 05:22:41 GMT

Has anybody managed to build groff to run under MS-DOS? I have
been trying to do it using djgpp, but make aborts at the first
test of c++ compilation.  Any useful suggestions?  Thank you in
advance.


Juan Antonio Rodriguez-Sero|People usually fail when they are on
jars@u.washington.edu      |                  the verge of success.
School of Oceanography     |So give as much care to the end as 
University of Washington   |                  to the beginning;
WB - 10, Seattle, WA 98195 |Only then there will be no failure. 
(206) 543 - 7003           |                           (Lao Dzu)

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: groff 1.05 with gcc 2.2.2 problem?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 14:56:15 GMT

   I finally installed gcc 2.2.2 and groff is the only c++ program I use...
   So I went to remake (after I installed libg++ 2.2.

   I got:
   leisner@trianguli$ make
   ...
   g++ -c -I. -g -O    -DHAVE_VFORK  -DHAVE_MMAP -DHAVE_RENAME    -DWAIT_COREDUMP_0200 -DNO_SYS_WAIT_H  errarg.c
   errarg.c: In method `errarg::errarg (const char *)':
   errarg.c:26: assignment between incompatible pointer types
   make[1]: *** [errarg.o] Error 1
   make: *** [lib] Error 1


   What's wrong?

This is a bug in gcc/g++ 2.2.  You can work around it like this:

*** errarg.c.~1~	Sat Jan 19 10:59:16 1991
--- errarg.c	Wed Jul  1 10:14:33 1992
***************
*** 22,28 ****
  #include "assert.h"
  #include "errarg.h"
  
! errarg::errarg(const char *p) : s(p == 0 ? "(null)" : p), type(STRING)
  {
  }
  
--- 22,28 ----
  #include "assert.h"
  #include "errarg.h"
  
! errarg::errarg(const char *p) : s(p ? p : "(null)"), type(STRING)
  {
  }
  
James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug