HDTenEightyP/NetNews huggingface dataset:
From: stefan@mpi-sb.mpg.de (Stefan Naeher)
Subject: Bug in Rational class of g++-2.3
Reply-To: stefan@mpi-sb.mpg.de
Organization: Max-Planck Institut fuer Informatik
Distribution: gnu
Date: Fri, 8 Jan 1993 11:49:31 GMT

Class Rational seems to have problems with zero values, e.g., the following 
program exits with the error message "Rational Error: Zero denominator"


#include <Rational.h>

main()
{
  Rational r1 = 17;

  Rational r = r1 - 0;
}

Is this a known bug, can it be fixed easily ?


-------------------------------------------------------------------------------
Stefan N"aher                                      e-mail: stefan@mpi-sb.mpg.de
Max-Planck-Institut f"ur Informatik                phone:  +49 681 302 5420
Im Stadtwald                                       fax:    +49 681 302 5401
6600 Saarbr"ucken
Germany
-------------------------------------------------------------------------------



Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Bug in libg++-2.3 (using setfill/setw in iomanip).
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 16:20:03 GMT

> have discovered
> what I think is a bug in the newly-added manipulators in iomanip.h.

No, the problem is in ostream::operator<<(char), and is old.
The problem is that I followed the documentation (the AT&T man pages,
and the draft ANSI standard), while AT&T felt no such obligation
to follow their own documentation.

I will probably change my code, assuming the ANSI draft gets modified.

But thanks for trying this out - there was a question whether
ANSI should follow the AT&T documentation or their implementation;
being able to point to an example in Stroustrup's book would
tend to favor the latter.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: jimc@pic.ucla.edu
Subject: Normal.cc may not be normal
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 08:46:18 GMT

Gnu g++ v2.3.2 for Sparc-Sun-SunOS 4.1.1.  libg++ v2.3.  

In Normal.cc, I am not sure that the given algorithm gives an exactly
normally distributed pair of results.  I have included a modification
implementing the Box-Muller algorithm, which is exact, at the cost of
a sin/cos evaluation.  

James F. Carter        (213) 825-2897
UCLA-Mathnet;  6221 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90024-1555
Internet: jimc@math.ucla.edu            BITNET: jimc%math.ucla.edu@INTERBIT
UUCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc

----------- From libg++.2.3/libg++/src/Normal.cc

double Normal::operator()()
{
    
    if (haveCachedNormal == 1) {
	haveCachedNormal = 0;
	return(cachedNormal * pStdDev + pMean );
    } else {
	
	for(;;) {
	    double u1 = pGenerator -> asDouble();
	    double u2 = pGenerator -> asDouble();
	    double v1 = 2 * u1 - 1;
	    double v2 = 2 * u2 - 1;
	    double w = (v1 * v1) + (v2 * v2);
	    
//
//	We actually generate two IID normal distribution variables.
//	We cache the one & return the other.
// 
	    if (w <= 1) {
		double y = sqrt( (-2 * log(w)) / w);
		double x1 = v1 * y;
		double x2 = v2 * y;
		
		haveCachedNormal = 1;
		cachedNormal = x2;
		return(x1 * pStdDev + pMean);
	    }
	}
    }
}

------------ Suggested change

// Reference: Ripley, Brian D.  Stochastic Simulation.  Wiley (NY) 1987.
// p. 54, algorithm 3.1, Box-Muller (not Mu\"ller).
double Normal::operator()()
{
    
    if (haveCachedNormal == 1) {
	haveCachedNormal = 0;
	return(cachedNormal * pStdDev + pMean );
    } else {

//	Get 2 flat random variables in 0..1.  Generator gives 0 <= u1 < 1.
	double u1 = pGenerator -> asDouble();
//	This one must never be zero.
	double u2;
	while (0.0 == (u2 = pGenerator -> asDouble())) /*null stmt*/;
	    
//
//	We actually generate two IID normal distribution variables.
//	We cache the one & return the other.
// 
	double th = 6.28318530717958648 * u1
	double r = sqrt(-2 * log(u2));
		
	haveCachedNormal = 1;
	cachedNormal = r * sin(th);
	return(pStdDev*r*cos(th) + pMean);
    }
}


Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Bug in Rational class of g++-2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 9 Jan 1993 10:25:01 GMT

> Is this a known bug, can it be fixed easily ?

It is not known to me.  Could you track it down, please?

	--Per Bothner
Cygnus Support     bothner@cygnus.com


Newsgroups: gnu.g++.lib.bug
From: rflewell@apg.andersen.com (Rich Flewelling)
Subject: libg++ testing
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 15:32:33 GMT

Dear Sir;

I am exploring how to make objects "Self-Testing" and was told that the
classes withing the libg++ library have methods that allow the objects to
test themselves.

Do you have any information on your approach to this problem and if so
where I can get it?

Thanks for your help

Rich Flewelling
rflewell@apg.andersen.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ cout can't be piped
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 15:00:12 GMT

The following patch should fix the problem.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

===================================================================
RCS file: /rel/cvsfiles/devo/libg++/iostream/stdiostream.C,v
retrieving revision 1.7
diff -c -r1.7 stdiostream.C
*** 1.7	1992/12/22 22:42:54
--- stdiostream.C	1992/12/31 02:47:51
***************
*** 87,94 ****
--- 87,97 ----
      if (!(xflags() & _S_NO_WRITES))
  	if (fflush(_file))
  	    return EOF;
+ #if 0
+ 	// This loses when writing to a pipe.
      if (fseek(_file, 0, SEEK_CUR) == EOF)
  	return EOF;
+ #endif
      return 0;
  }
  

Newsgroups: gnu.g++.lib.bug
From: gml4410@ggr.co.UK (Lack Mr G M)
Subject: Error building libg++-2.3 on SG Indigo
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 17:52:51 GMT

     I  have  just  built  libg++-2.3  on  an SG Indigo (Irix 4.0.1) and
obtained an error during the checks.  The build was with gcc-2.3.3 using
./configure  mips-sgi-irix4.  I'm not sure whether the problem is in the
compiler or the library, so I'm posting this message to both bug lists. 


     The log of the build at the point of the error looks like this:

        gcc -O -nostdinc++ -I. -I../.. -I./.. -I./../stdio -I./../../g++-include  -c tformat.C
        gcc -o tformat tformat.o ../libio.a ../../libg++.a
        ./tformat
Encountered no errors in 3988 tests.
Virtual memory exceeded in `new'
*** Error code 255

Stop.


     If  I  compile  tformat.C with a "-D__PCCNECV70__" option then only
ca.  250 tests are included and the "cut-down" tformat executes  without
error. 


     The  problem I see here is that the test has actually completed (it
has reported no errors in its 3988  tests)  and  hence  the  program  is
terminating.   So why is there an error in "new"?  What is being created
on exit? 


-------------------------- Gordon Lack ----------------------------------
The contents of this message *may* reflect my personal opinion.  They are
*not* intended to reflect those of my employer, or anyone else.

Newsgroups: gnu.g++.lib.bug
From: bartm@cv.ruu.NL (Bart Muyzer)
Subject: Undefined symbols?? (building libg++ 2.3 with gcc 2.3.3 on HP9k700)
Organization: University of Utrecht, 3D Computer Vision Research Group
Distribution: gnu
Date: Fri, 8 Jan 1993 08:45:57 GMT

Hello,

[Sorry if you see this message more than once; there seems to be something
wrong with posting to "world"...]

As a followup to the patches I posted a while ago which make libg++ 2.2 work
for HP9000/700 with gcc 2.3.1, I'm currently porting libg++ 2.3 to the
9000/700. I use gcc 2.3.3 fo this.

The port has been fairly easy so far, however one problem remains that I
haven't been able to solve yet:

While running "make check" in libg++/etc/fib I get:

  gcc -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../li bg++.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status
*** Error code 1

Adding a little more verbosity, I get:

  gcc -v -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../libg++.a
  Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
  gcc version 2.3.3
   /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/ld -u main -a archive -o fib /lib/crt0.o fib.o ../../libg++.a /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a -lc /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status

Poking around in libg++ learned me that all of the symbols aren't even there!!

I compiled libg++ 2.3 with gcc 2.3.3 so it cannot be the "name mangling
problem" described by Brendan Kehoe (I guess).

The funny thing is that when I link with libg++ 2.2 (built with gcc 2.3.1),
all works well. In libg++ 2.2, the symbols seem to come from the "iostream.o"
module.

Could anybody please help me with this? I would like to post a new set of
patches ASAP to share my experiences...

Any help will be greatly appreciated!

							>] Bartm [<
-- 
Bart Muyzer, Systems and Network Administrator, [NIC-Whois handle: BJM9]
     3D Computer Vision, Room E02.222, University Hospital Utrecht,
     Heidelberglaan 100, 3584 CX Utrecht, Holland. E-mail: bartm@cv.ruu.nl
     Fax: +31-30-513399. Tel: +31-30-506711 (w), +31-3402-52157 (h). 


Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ testing
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 9 Jan 1993 10:23:33 GMT

I don't know what you mean.  There are a number of test programs
with libg++, but that is perhaps not what you mean.
I suggest you ask whoever told you about "libg++ self-testing"
to explain what they meant.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: garp@isy.liu.se (Johan Garpendahl)
Subject: strstream bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 18:16:47 GMT

I'm not quite sure that this is a bug, it's rather a difference in how
cfront handles strstreams and how (lib)g++ handles strstreams. 

Here is an example:
////////////////////////////
#include <string.h>
#include <strstream.h>
#include <iostream.h>

char* str1="Now is the time for all good men ... 13:34:20 beep";

main()
{
    istrstream istr1(str1, strlen(str1) + 1);
    char buf[256];

    while(istr1 >> buf) cout << buf << " "; // Don't forget to say "beep"
    cout << endl;

    istrstream istr2(str1, strlen(str1) + 1);

    while(istr2.good()) { // Try again!
	istr2 >> buf;			  // That's better!
	cout << buf << " ";
    }
    cout << endl;
}
////////////////////////////

Compile with cfront and it prints the whole string twice.
Compile with (lib)g++ and it loses the "beep" the first time.

I can find good arguments for both behaviours.
Is it the program that is badly written?
Is there a definition of how it should work?

BTW, I last tried it with g++-2.3.3 and libg++-2.3.

Regards, 

	Johan
___________________________________________________________________________
Johan Garpendahl                   | Email: garp@isy.liu.se
Linkoping University               | Phone: +46 - 13 - 28 13 24
Dept. of Electrical Engineering    | Fax  : +46 - 13 - 13 92 82
S-581 83  LINKOPING // SWEDEN      | May the Source be with you.


Newsgroups: gnu.g++.lib.bug
From: bartm@cv.ruu.NL (Bart Muyzer)
Subject: Undefined symbols?? (building libg++ 2.3 with gcc 2.3.3 on HP9k700)
Keywords: iostream, undefined
Organization: University of Utrecht, 3D Computer Vision Research Group
Distribution: gnu
Date: Thu, 7 Jan 1993 16:21:06 GMT

Hello,

As a followup to the patches I posted a while ago which make libg++ 2.2 work
for HP9000/700 with gcc 2.3.1, I'm currently porting libg++ 2.3 to the
9000/700. I use gcc 2.3.3 fo this.

The port has been fairly easy so far, however one problem remains that I
haven't been able to solve yet:

While running "make check" in libg++/etc/fib I get:

  gcc -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../li bg++.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status
*** Error code 1

Adding a little more verbosity, I get:

  gcc -v -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../libg++.a
  Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
  gcc version 2.3.3
   /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/ld -u main -a archive -o fib /lib/crt0.o fib.o ../../libg++.a /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a -lc /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status

Poking around in libg++ learned me that all of the symbols aren't even there!!

I compiled libg++ 2.3 with gcc 2.3.3 so it cannot be the "name mangling
problem" described by Brendan Kehoe (I guess).

The funny thing is that when I link with libg++ 2.2 (built with gcc 2.3.1),
all works well. In libg++ 2.2, the symbols seem to come from the "iostream.o"
module.

Could anybody please help me with this? I would like to post a new set of
patches ASAP to share my experiences...

Any help will be greatly appreciated!

							>] Bartm [<
-- 
Bart Muyzer, Systems and Network Administrator, [NIC-Whois handle: BJM9]
     3D Computer Vision, Room E02.222, University Hospital Utrecht,
     Heidelberglaan 100, 3584 CX Utrecht, Holland. E-mail: bartm@cv.ruu.nl
     Fax: +31-30-513399. Tel: +31-30-506711 (w), +31-3402-52157 (h). 


Newsgroups: gnu.g++.lib.bug
From: mario@ing.puc.cl (Mario Droguett Cartagena)
Subject: Problems with gcc-2.3.1 & libg++-2.2
Followup-To: poster
Organization: Pontificia Universidad Catolica de Chile
Distribution: gnu
Date: Fri, 8 Jan 1993 20:06:53 GMT

Hello folks.

I'm trying to compile gcc-2.3.1 & libg++-2.2 in a Unisys U6000/65 (2
486 processors), running SYSV R4.0, but I'm having several problems:

Gcc (aparently) compiles fine, but, when compiling libg++ ...

	...
	gcc -g -nostdin++ -I.. -I. -I./../iostream -I./../g++-include \
-c AllocRing.cc
	(EOF): undefined name: .L_T51
	(EOF): undefined name: .L_B5_e
	(EOF): undefined name: .L_B5

and the compilation aborts.

I don't know what's happening, because when I try to compile normal C++
source code (only one class in the file, without inheritance and
polimorfism, no virtual members, etc), it compiles without any
troubles. 

Please help me !!! (I'm desesperate ...)

	       			Thanks in advance.

(Please, reply by mail to mario@ing.puc.cl)


--
             \\__  o   
         |\/    o\  o
         >       < o		Mario A. Droguett Cartagena
         |/\   __/
             //			mario@ing.puc.cl
....................................

Newsgroups: gnu.g++.lib.bug
From: dvallone@srg.UUCP (Dan Vallone x4455)
Subject: Re: SCO 386 Build of libg++-2.3
Keywords: success building libg++-2.3 under SCO
Organization: ARINC Research, Corp.
Distribution: gnu
Date: Tue, 5 Jan 1993 18:14:54 GMT

J. Steven Harrison writes:
> I am trying to build libg++-2.3 on a Intel 486 box running SCO UNIX 3.2v4

> This is config.status
> --------------------------------------------------
> #!/bin/sh
> # This file was generated automatically by configure.  Do not edit.
> # This directory was configured as follows:
> ./configure i386-sco3.2v4 --prefix=/usr/local -norecursion 
> # using "config/mh-sco"
> --------------------------------------------------

I had very little problems building libg++-2.3 under SCO's ODT 1.1
op. system.  About all I did was to add .NOEXPORT: to a few Makefiles.
I also had to add some floating point defs to the file floatconv.C

I used gcc-2.3.3 which also built extremely easily.

Let me know if you need diffs for the 3 or 4 files I had to alter.

-Dan

-- 
+----------------------------------------------------------------------+
| Daniel E. Vallone                                                    |
| Arinc Research Inc                   uunet!srg!dvallone              |
| SR, Mail Stop 5-230                  dvallone%srg@uunet.uu.net       |
| 2551 Riva Road                                                       |
| Annapolis, MD 21401            fax: 410-266-4419 voice: 410-266-4455 |
+----------------------------------------------------------------------+
--
+----------------------------------------------------------------------+
| Daniel E. Vallone                                                    |
| Arinc Research Inc                   uunet!srg!dvallone              |
| SR, Mail Stop 5-230                  dvallone%srg@uunet.uu.net       |

Newsgroups: gnu.g++.lib.bug
From: cc971@cleveland.FReenet.EDU (Stephen  C. Fitch)
Subject: Problems building libg++2.3
Reply-To: cc971@cleveland.freenet.edu (Stephen  C. Fitch)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Distribution: gnu
Date: Tue, 5 Jan 1993 16:56:45 GMT

I recently posted a problem encountered while attempting
to build libg++2.3 under SunOS 4.13 on a Sun4c box. I
still have not found a solution. Can someone who
has built GCC 2.3.2 and libg++2.3 please describe
their environment. I am in the situation where I need
to build the new compiler and library along side an
old gcc 1.37 installation.

I'd be interested in tips from anyone else who has
managed this. I have:

drwxr-xr-x  2 steve         512 Dec 23 16:31 bin
drwxr-xr-x 11 steve        1024 Dec 24 09:28 binutils-2.0
drwxr-xr-x  2 5200         2048 Dec 23 10:27 bison-1.19
drwxr-xr-x  6 steve        9216 Dec 24 14:08 gcc-2.3.2
drwxr-xr-x  2 steve         512 Dec 24 14:09 include
drwxr-xr-x  2 steve         512 Dec 23 10:24 info
drwxr-xr-x  3 steve         512 Dec 23 15:58 lib
drwxr-xr-x  7 steve         512 Jan  5 15:07 libg++-2.3
-rw-rw-rw-  1 steve     1718057 Dec 23 09:56 libg++-2.3.tar.Z
drwxr-xr-x  3 steve         512 Dec 23 15:58 man
-rw-r--r--  1 steve       87398 Jan  5 15:51 typescript

Below /usr/local/tmp. Other problems I have noticed
when I try to make the library include the 'configure'
processor does not recurse my subdirs and as mentioned
in my previous message I get errors while gen'ing dummy.


If I need to be more specific in any area let me know and
I'll provide the details.

Steve Fitch


Newsgroups: gnu.g++.lib.bug
From: filipi@cebaf9.cebaf.gov (Adrian Thomas Filipi-Martin)
Subject: Re: libg++ 2.3 and gcc 2.3.3 on HP9k700; unsatisfied symbols??
Keywords: iostream
Reply-To: adrian@cs.wm.edu
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Distribution: gnu
Date: Fri, 8 Jan 1993 15:43:05 GMT

--
In article <1993Jan7.110644.14286@cv.ruu.nl>, bartm@cv.ruu.NL (Bart
Muyzer) writes:
|> Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
|> gcc version 2.3.3
|> /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/ld -u main -a archive -o fib
|>/lib/crt0.o fib.o ../../libg++.a
|>/usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a -lc
|>/usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a
|> ld: Unsatisfied symbols:
|>    __ls__FR7ostreamd (code)
|>    __ls__FR7ostreami (code)
|>    __ls__FR7ostreamPCc (code)
|> collect: /bin/ld returned 1 exit status
|>
|>It turns out that the "Unsatisfied symbols" aren't even in the just
|>build
|>libg++.a!!????
|>
|>When I link with version 2.2 of libg++, all works well. In libg++ 2.2,
|>the
|>"Unsatisfied symbols" seem to come from the file 'iostream.o'.
|>

Try putting 'setenv LDOPTS -L /usr/local/lib' in your .cshrc. I just
expierienced
a similar linker problem when I installed gcc yesterday on a 345 w/8.0.

The hp linker doesn't look in any directories other than /lib. :(.

Hope this helps.

Adrian
----------------------------------+--------------------------------------------
adrian@cs.wm.edu          ---->>>>| Support you local programmer,
adrian@cebafi.cebaf.gov     --->>>| STOP Software Patent Abuses NOW!
Member: The League for        -->>| membership info at prep.ai.mit.edu:/pub/lpf
       Programming Freedom      ->| print "join.ps" for an application
----------------------------------+--------------------------------------------

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++ 2.3 and gcc 2.3.3 on HP9k700; unsatisfied symbols??
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 9 Jan 1993 10:05:50 GMT

> Try putting 'setenv LDOPTS -L /usr/local/lib' in your .cshrc.

I think this is the wrong advice.

The problem seems to be that the way the names od the methods
in ipostream.C is inconsistent between libg++ and your application.
This looks like some kind of version mismatch problem.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.groff.bug
From: bill@wafbox.gwinnett.COM (Bill Fulton)
Subject: Re: Problems building groff-1.06 with g++-2.3.3, libg++-2.3
Organization: (Home)
Distribution: gnu
Date: Sun, 10 Jan 1993 06:52:49 GMT

In article <1992Dec29.225608.25982@uicc.com> putsch@uicc.com (Jeff Putsch) writes:
>Howdy,
>
>I'm attempting to build groff-1.06 using g++-2.3.3,
>GROFF VERSION: 1.06
>MACHINE: DEC DECstation 5000/200
>OS: ULTRIX 4.3
>COMPILER: g++ 2.3.3
>INPUT FILES: 
>COMMAND LINE: make
>DESCRIPTION OF INCORRECT BEHAVIOUR: error during compilation of pic/
>SUGGESTED FIX [optional]: NONE
>object.cc: In method `circle_object::circle_object (double)':
>object.cc:1030: Internal compiler error.
>object.cc:1030: Please report this to `bug-g++@prep.ai.mit.edu'.
>make[2]: *** [object.o] Error 1
>make[1]: *** [pic] Error 1
>make: *** [all] Error 1

This is covered in the "PROBLEMS" file - says not to use the "-O" switch.

-- 
Bill Fulton            (Home Alone) |    Grab .. 
    bill@wafbox.gwinnett.com        |            The ..
OR  ..!gatech!dcatla!wafbox!bill    |                   Reins

Newsgroups: gnu.groff.bug
From: rgn@cs.appstate.EDU (Rob Norris)
Subject: Problem building groff 1.06
Organization: Appalachian State University
Distribution: gnu
Date: Tue, 5 Jan 1993 19:15:29 GMT

Hello,

I am trying to build groff 1.06 on a DS5000/125 running Ultrix 4.2a.
Compiler is gcc 2.3.3.  Here is the tail end of a make attempt:

====================
Making all in devps
rm -f DESC
cat ./DESC.in >DESC
echo broken 0 >>DESC
if test "letter" = A4; then    echo "paperlength 841890" >>DESC;  else    echo "
paperlength 792000" >>DESC;  fi
test -z 'lpr -Psp' ||   echo print 'lpr -Psp' >>DESC
*** Error code 1

Stop.
*** Error code 1

Stop.
*** Error code 1

Stop.
====================

Any ideas?

Thanks for any help!
--
Rob Norris
rgn@cs.appstate.edu
(704)262-2296

Newsgroups: gnu.groff.bug
From: sjaak@athena.research.ptt.nl (Sjaak Schilperoort)
Subject: Re: Help w/ compiling on SunOS 4.1.2
Reply-To: J.W.Schilperoort@research.ptt.nl
Organization: PTT Research, The Netherlands
Distribution: gnu
Date: Fri, 8 Jan 1993 16:01:37 GMT

jennings@lhotse.stortek.COM (Jeff Jennings) writes:

>Sjaak Schilperoort (sjaak@athena.research.ptt.nl) wrote:
>> brian@natinst.com (Brian H. Powell) writes:

>> >     As I'm sure many of you know, groff 1.06 doesn't compile easily on a Sun
>> >running SunOS 4.1.2 with gcc/g++ 2.3.3 (and several earlier versions of
>> >g++ 2.x).  So, I'm looking for advice on how to accomplish this task.

>I just compiled groff 1.06 with gcc/g++-2.3.3 on SunOS 4.1.3 without a single
>problem or warning.  All I did was type "configure" and then "make".

>> [...]

>I just tried this in the libg++/src directory, with your program stored as
>x.cc, and got no errors or warnings.  It compiled just fine.  I can't really
>speculate on what your problems might be, are you guys sure you configured
>everything correctly, and ran "make fixincludes" when you built gcc?

I used to `make fixincludes' when installing gcc on all systems. Nowadays 
the INSTALL-file for gcc mentions:
     Note that some systems are starting to come with ANSI C system
     header files.  On these systems, don't run `install-fixincludes';
     it may not work, and is certainly not necessary.
I presumed that SunOS was one of those systems, so I didn't make
fixincludes anymore (and subsequently forgot all about it).

Thanks for correcting this, no problems with compiling libg++/groff 
anymore!

			Sjaak.
-- 
Sjaak Schilperoort                   J.W.Schilperoort@research.ptt.nl
PTT Research, The Netherlands

Newsgroups: gnu.groff.bug