HDTenEightyP/NetNews huggingface dataset:
From: int401a@mdw045.cc.monash.edu.au (Mr D. Vladicic)
Subject: C++ construtor problem  
Organization: Monash University
Date: Wed, 9 Sep 1992 01:16:32 GMT


Iam a final year computer science student currently working on a
c++ project.  The problem i have is that when i make my program
i get the following message

ld:
Undefined:
_$_4User
collect: /usr/bin/ld returned 1 exit status
*** Error code 1


i have linked the program to all its components e.g User 
the program  will compile except it wont give executable
permission to the final object code.

	When i change mode the program will complete all its tasks 
	till it finishes at which point it gives a segmentation fault

WHAT I  would like to KNOW is what causes the error is it the User constructor
or is it something else
		example of the constructor is provided below

		User::User(String& user_name,String& password)
{
       	
        person= new Personal;  // simple struct 
        if (!Check_password(user_name, password))
                {
                        cout<<" you bombed" << endl;
                        exit(1);
                        //give an error message and abort
                        
                }


          Finances=new Financial(user_name);     
          History=new Tipping_History(user_name);
}
			
		any assistance would be greatly appreciated

				int401a@mdw045.cc.monash.edu.au
				Dragan Vladicic
Newsgroups: gnu.g++.help
From: edstrom@Elmer.hsc.ucalgary.ca (John Edstrom)
Subject: how to do this?
Date: Thu, 10 Sep 92 20:33:59 GMT
Distribution: gnu
Organization: Neuroscience Division, U of Calgary School of Medicine, Calgary, Alberta, Canada



I am trying to convert some C++ code to g++.  What is wrong with the
following constructions and how can I do it in g++?

----------

class a {
public: 
	int x();
};

int a::x() { return 1; }

main() {
	printf("%x\n", (int(*))a::x);
}


the compiler complains that it cannot convert a::x to a pointer


what am I doing wrong?

JE
--
 RM 2104, HSc Building,  Div. Neuroscience
 U. Calgary School of Medicine,  3330 Hospital Drive NW
 Calgary, Alberta       T2N 3Y4
 (403) 220 4493  (wk)
Newsgroups: gnu.g++.help
Subject: Re: help with Random class
From: fsb@sparc.vitro.com (Steve Brailsford)
Date: 4 Sep 92 14:57:27 GMT
Keywords: random numbers

fsb@sparc.vitro.com (Steve Brailsford) writes:

>I see there is some kind of random number generator class
>in g++ lib.  Can someone give me an example on how to use it?
>It'd like say a random number between 10 and 20.  I think there
>is a way to get it to do that, but haven't figured out how.
>I wish there were some examples in the comments or something.
>Man pages would be nice too. :-)

To answer my own question, I have found some examples in the
libg++ test directory.  The one in particular that applies here is
tRandom.cc
I see now it needs a distribution function and what functions are
available.  Pretty neat.  These classes still need man pages. :-)

--
    Steve Brailsford (fsb@sparc.vitro.com)   _____
    Usenet:  uupsi!vitro!sparc!fsb         \/itro Corporation
    Voice:  (301) 231-1481                  14000 Georgia Ave.
    Fax:    (301) 231-2020                  Silver Spring, MD 20906
Xref: sparky gnu.g++.help:1229 gnu.gcc.help:2119
From: becker@mentor.cc.purdue.edu (Greg Becker)
Newsgroups: gnu.g++.help,gnu.gcc.help
Subject: g++-2.2 - make check fails in iostream subdir
Date: 14 Sep 92 17:04:04 GMT
Followup-To: gnu.g++.help
Organization: PUCC UNIX-Group


I'm trying to build libg++-2.2 on a SPARC Server 690MP.  Of course, I'm
experiencing the same problem on a SPARC IPC.  It seems the  library
builds just fine but will not pass `make check.'  In particular, it fails
with iostream/test/tFile.  The details follow, but the strange thing is
that tFile executes perfectly when output is not redirected.

I'm using gcc-2.2.2, and configured libg++2.2 as `sparc.'  The only
real success I've had in getting `make check' to pass is by setting IO_DIR to
nothing, and removing gperf from SUBDIRS and ALL (but that's after the
complete build.)

At this point, I can't be certain it is not a gcc installation problem,
although gcc built and installed without error (through stage 3).  I've tried
gcc configured with and without gas/gld.

Does anyone have any idea what might be wrong?

Thanks in advance!

Greg



cd genclass ; make check ::: AR=ar  AR_FLAGS=qc  CC=gcc  CFLAGS=  RANLIB=ranlib  LOADLIBES=  LDFLAGS=  MAKEINFO=makeinfo  XTRAFLAGS=
cd src ; make check ::: AR=ar  AR_FLAGS=qc  CC=gcc  CFLAGS=  RANLIB=ranlib  LOADLIBES=  LDFLAGS=  MAKEINFO=makeinfo  XTRAFLAGS=
cd iostream ; make check ::: AR=ar  AR_FLAGS=qc  CC=gcc  CFLAGS=  RANLIB=ranlib  LOADLIBES=  LDFLAGS=  MAKEINFO=makeinfo  XTRAFLAGS=
cd stdio; make check ...
cd test; make check ...
./tFile < ./tFile.inp > tFile.out 2>&1
diff -c tFile.out ./tFile.exp
*** tFile.out	Tue Sep  8 21:54:36 1992
--- ./tFile.exp	Fri Apr 17 18:49:17 1992
***************
*** 36,38 ****
--- 36,49 ----
  using it to create istrstream...
  with contents:
  This is a string-based stream.
+ With two lines.
+ 
+ Making filebuf streams fout and fin...contents of file:
+ Thisfilehasonelinetestingoutputstreams.
+ 
+ Final names & states:
+ cin:      (stdin)	0
+ cout:     (stdout)	0
+ cerr:     (stderr)	0
+ 
+ end of test.
Newsgroups: gnu.g++.help
From: west@chance.dsg.ti.com (Roger West)
Subject: GDB still skips breakpoints
Organization: Texas Instruments, Speech Mushrooms.
Date: Thu, 10 Sep 1992 06:52:52 GMT


Can anyone clue me in on why GDB still skips breakpoints when debugging g++
code?  Typically, breakpoints will only work the first time through, and will
be skipped thereafter.  This has been a problem for me since gdb 4.1 or 4.2,
and as useful as the g++/gdb/emacs environment is to me, this has been the
number one detriment to my programming productivity (well, not including those
occasional six packs of Bud Light).  Here's my context...

	g++ version 1.40.3 (based on GCC 1.40)
	GDB 4.6
	Sun4/110
	SunOS chance 4.1.1 2 sun4

As I have not yet had any spare time to try chasing this down, I am hopeful
someone else has already done the hard part.

Any info is greatly appreciated.

Roger
Newsgroups: gnu.g++.help
From: chr@bio129.uni-bielefeld.de (Christian Bartling)
Subject: Insufficient Stack Space
Date: Mon, 14 Sep 92 08:21:37 GMT
Organization: Universitaet Bielefeld
Keywords: GCC 2.2.2, Stack, C++

Hi,

I have some problems eihter with the link386 program, or with the GNU C++  
compiler itself. I programmed a small application, which consists mainly  
of three loops. It`s not a PM application. Everytime when running the  
program, it gets killed by OS/2 at a certain point with the message of "  
insufficient stack space". Increasing the stack space on the link386  
command line with the option "/STACK:xxxxx" does`t help. Is there a way to  
get the program running under OS/2 ???

Some addintional information:

The same C++ source gets compiled under Next-Mach with the GNU compiler  
GCC 2.1 and runs just fine. Also under MSDOS and Borland C++ there are no  
problems. What`s going on ??

---
Christian Bartling
chr@bio128.uni-bielefeld.de
Xref: sparky gnu.g++.announce:12 gnu.gcc.announce:32 comp.lang.c++:13343
From: rms@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.g++.announce,gnu.gcc.announce,comp.lang.c++
Subject: G++ 1.41.0 available
Date: 5 Sep 92 03:50:05 GMT
Followup-To: gnu@prep.ai.mit.edu
To: info-gcc@prep.ai.mit.edu

If you are using GCC 1.41 for C++, you should get G++ 1.41.0,
which is likewise available on prep.  Don't try to use G++ 1.40.*
with GCC 1.41.

There is no separate G++ distribution for GCC version 2; in version 2,
C++ support is integrated and contained in the GCC distribution.
Newsgroups: gnu.g++.lib.bug
From: vemula@athena.mit.edu
Subject: Files to test incremental linking
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 05:51:58 GMT

I am unable to locate the files test.hello.cc , test.bye and others 
which are referred to in the Makefile of the tests directory of libg++.
Could you tell me where I can find them?

thanks
murali

Newsgroups: gnu.g++.lib.bug
From: Nik_Gervae@next.com (Nik Gervae)
Subject: License for libg++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 08:54:19 GMT

Hello--

I don't know if this is the right place to ask this. Please accept my
apologies if it isn't.

I'm writing some technical documenation for using C++ with NeXTSTEP,
and would like to confirm the licensing status of libg++. I know that
some GNU products have a license that permits programs developed with
them to be sold commercially, while others have a license that
essentially requires the resulting product to be copylefted. What I
need to know is the flavor of license for libg++ so I can mention it.

Any information you could send my way is greatly appreciated.

--
Nik Gervae
Software Publications, NeXT Computer, Inc.
ngervae@next.com
[[[[NXDisclaimer alloc] init] disclaim] free];

Newsgroups: gnu.g++.lib.bug
From: earl@alps.UUCP (Earl Killian)
Subject: problem with libg++-2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 6 Sep 1992 18:02:09 GMT

I compiled libg++-2.2 with gcc-2.2.2 (--with-gnu-ld), gas-1.38, and
binutils-2.0/ld.  When I did make install I got an error from one of
the tests:

`if [ -f ../../gcc/gcc ] ; then echo ../../gcc/gcc -B../../gcc/ ; else echo gcc ; fi`  -nostdinc++ -I.. -I. -I./../src -I./../iostream -I./../g++-include `if [ -f ../../gcc/gcc ] ; then echo -I./../../gcc/include ; else echo ; fi`  -c foo_main.cc
`if [ -f ../../gcc/gcc ] ; then echo ../../gcc/gcc -B../../gcc/ ; else echo gcc ; fi` -g -v  -o foo_main.run  foo_main.o foo_func.o Foo.o ../libg++.a
Reading specs from /usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 ld -e start -dc -dp -o foo_main.run /lib/crt0.o -L/usr/local/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2 -L/usr/local/gnu/lib foo_main.o foo_func.o Foo.o ../libg++.a -lgcc -lc -lg -lgcc
./foo_main.run > foo_main.out
diff ./expected.out foo_main.out >foo_main.diff
make: *** [foo_main.diff] Error 1
Exit 1
alps% cat foo_main.diff
14,15d13
< Destructing Foo(2) "static_foo" (remaining foos: 1)
< Destructing Foo(1) "static_foo" (remaining foos: 0)
From: cohen@merak.greco-prog.fr (Henri Cohen)
Newsgroups: gnu.g++.lib.bug
Subject: bug report
Date: 14 Sep 92 21:04:33 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I have already sent a less detailed report to D. Lea, so sorry
if this is a repost.

When compiling Integer.cc with gcc-2.2.2 on a 68020/68881 machine
(a Sony News, but I don't think it matters), I get the warning
"float or double assigned to integer data type" in function hypot
of math-68881.h. This is strange, and can be "corrected" if the
#include math.h statement is put BEFORE the #include Integer.h
statement in the file Integer.cc. I do not understand this behavior
or why this "correction" should work.

H. Cohen

cohen@alioth.greco-prog.fr
Newsgroups: gnu.g++.lib.bug
From: lewis@sophists.COM (Lewis G. Pringle)
Subject: iostream library fstream: :attach (int fd) in libg++ 2.1
Reply-To: lewis@sophists.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 00:38:00 GMT

	The ATT C++ 2.1 iostream library has an attach (int fd) method
in filestream base, and it is inherited in fstream, ifstream, and ofstream.

	In libg++ 2.1 the filebuf class has this method, and you can
get at this object from the Xfstream but for ATT compatability, you probably
should add this method to fstream, ifstream, and ofstream.

				Lewis.


Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: built-in prototypes?
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Fri, 4 Sep 1992 21:11:29 GMT

bothner@cygnus.com writes:

>libg++ extracts a definition of size_t from the system header
>files (in the script libg++/utils/gen-params).  So basically,
>gcc's definition of size_t as int (which contradicts ANSI, but
>matches most recent releases of SunOS) does not match your
>system's header files.  You could fix gcc (by changing its
>definition of SIZE_TYPE).

If you are compiling libg++ with gcc (as I would assume), the size_t
defined in the gcc headers (i.e. stddef.h) should take precedence over the
system headers, I feel.  Thus:

*** /gnu/libg++/libg++/utils/gen-params~	Fri Jun 26 12:29:41 1992
--- /gnu/libg++/libg++/utils/gen-params	Fri Sep  4 14:06:22 1992
***************
*** 107,113
  # using sed to search for typedefs in the output.
  
  cat >dummy.c <<!EOF!
- #include <sys/types.h>
  #include <stddef.h>
  #include <stdarg.h>
  #include <stdio.h>

--- 107,112 -----
  # using sed to search for typedefs in the output.
  
  cat >dummy.c <<!EOF!
  #include <stddef.h>
  #include <sys/types.h>
  #include <stdarg.h>
***************
*** 109,114
  cat >dummy.c <<!EOF!
  #include <sys/types.h>
  #include <stddef.h>
  #include <stdarg.h>
  #include <stdio.h>
  #include <time.h>

--- 108,114 -----
  
  cat >dummy.c <<!EOF!
  #include <stddef.h>
+ #include <sys/types.h>
  #include <stdarg.h>
  #include <stdio.h>
  #include <time.h>
-- 
Fool on a Pedestal
From: lewis@sophists.COM (Lewis G. Pringle)
Newsgroups: gnu.g++.lib.bug
Subject: size_t should be typedef
Date: 9 Sep 92 00:37:00 GMT
Reply-To: lewis@sophists.com
Distribution: gnu
Organization: GNUs Not Usenet

In libg++ 2.1 it seems that size_t is made to be a #define. This has the
unfortunate side-effect of breaking code which uses functional cast notation
to cast to type size_t.

eg:
	size_t	fred	=	size_t (1);

fails to compile, because size_t is expanded as a #define to unsigned int.

If you must check all over the place if it is defined, why not use __size_t or
some such thing? Or at least, if you MUST use a #define here, please #define to
a simple type name - (first cons up bogus typedef like
typedef unsigned int _nobody_would_ever_use_this_, and then #define size_t _nobody_would_ever_use_this_.
At least this way, my code would compile :-).


			Lewis.
Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Does libg++ 1.41 exist?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 20:55:27 GMT

> I was wondering if there are plans for libg++ 1.41? With iostreams?

No.
	--Per

Newsgroups: gnu.g++.lib.bug
From: brendan@autodesk.UUCP (Brendan Kehoe)
Subject: Re: help with Random class
Reply-To: autodesk!brendan%cygnus.com@uunet.uu.net
Organization: Cygnus Support, Palo Alto CA; Phone +1 415 322 3811
Distribution: gnu
Date: Sun, 6 Sep 1992 04:34:25 GMT

In article <fsb.715618647@sparc> fsb@sparc.vitro.com (Steve Brailsford) writes:

   I see now it needs a distribution function and what functions are
   available.  Pretty neat.  These classes still need man pages. :-)

Yup--please write some.  The information's all in libg++.texinfo.
--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811
                       Oooh! A handsome stranger! And me, without my shoes on.
                                     --The Princess, The Emperor's New Clothes

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Errors compiling libg++ (v2.2) using g++ (v2.2.2) on Alliant FX/2800
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 16:20:34 GMT

> warning: implicit declaration of function `__builtin_args_info'

This is probably a gcc problem.  Try compiling a C program
using va_start - you should probably have the same problem
at link time (but no compiler warning a compile time).
If so, report it to whoever is maintaing teh alliant port
and/or the gcc bug mailing list.

	--Per Bothner
Cygnus Support     bothner@cygnus.com
From: kelly@ipld01.hac.com (Keith Kelly)
Subject: Errors compiling libg++ (v2.2) using g++ (v2.2.2) on Alliant FX/2800
Organization: Hughes Aircraft Company - Canoga Park, CA
              Imaging Guidance Design Laboratory
Distribution: gnu
Date: Fri, 4 Sep 1992 22:47:43 GMT

I'm trying to build the gnu libg++ (version 2.2) library using the gnu g++
(version 2.2.2) compiler on an Alliant FX/2800.  Whenever it tries to
compile any routine with the va_start function, it complains with:

warning: implicit declaration of function `__builtin_args_info'

The libg++ library eventually builds but it has unresolved references to
__builtin_args_info.  The va-i860.h references this function in the va_start
routine but it is unclear where this function is actually defined.  Any
suggestions?  Thanks in advance.

          
-- 
Keith Kelly                    Internet   : kelly@ipla01.hac.com         
"Of all the things I've lost   UUCP       : ...!usc!!hacgate!ipla01!kelly
 I miss my mind the most"      Phone      : (818) 702-2328

Newsgroups: gnu.g++.lib.bug
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Subject: Does libg++ 1.41 exist?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 14:05:34 GMT

Having seen the announcement for gcc/g++ 1.41, I was
wondering if there are plans for libg++ 1.41? With iostreams?

Gordon,

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: built-in prototypes?
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sun, 6 Sep 1992 01:04:39 GMT

In article <1992Sep4.211129.25826@muddcs.claremont.edu> jason@jarthur.claremont.edu (Jason Merrill) writes:

>If you are compiling libg++ with gcc (as I would assume), the size_t
>defined in the gcc headers (i.e. stddef.h) should take precedence over the
>system headers, I feel.

OK, I was wrong.  Since stddef.h says size_t is unsigned long no matter
what SIZE_TYPE was when gcc was compiled, obviously it can't be trusted,
and the system headers should take priority.

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.groff.bug
From: josema@oceania.INf.ISei.jrc.IT (Jose Maria Torres)
Subject: HELP: building groff on Sparc
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 18:18:57 GMT

GROFF VERSION:	1.06

MACHINE: Sun Sparcstation 1+ & Sun Sparcstation 2

OS: SunOS 4.1.1 & SunOS 4.1.2

COMPILER: GCC 2.2.2

INPUT FILES: none

COMMAND LINE: make

DESCRIPTION OF INCORRECT BEHAVIOUR:

-> make
Making all in include
Making all in libgroff
........
gcc -O -I. -I. -I../include -I./../include -DHAVE_UNISTD_H=1
-DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1
-DHAVE_CC_LIMITS_H=1 -DLONG_FOR_TIME_T=1 -DHAVE_MMAP=1 -DHAVE_VFORK_H=1
-DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_SYS_SIGLIST=1 -DWCOREFLAG=0200
-g  -c device.cc
/usr/include/stdlib.h: In method `device_init::device_init ()':
/usr/include/stdlib.h:28: too many arguments to function `char * getenv ()'
device.cc:33: at this point in file
*** Error code 1
make: Fatal error: Command failed for target `device.o'
Current working directory
/net/is.iss.isei.jrc.it/shadow/sun4.sos4/gnu/groff/libgroff
*** Error code 1
make: Fatal error: Command failed for target `libgroff'
Current working directory /net/is.iss.isei.jrc.it/shadow/sun4.sos4/gnu/groff
*** Error code 1
make: Fatal error: Command failed for target `all'
-> 

SUGGESTED FIX: none

Please, any help would be appreciated.

Jose Perdigao
Jose M. Torres

Newsgroups: gnu.groff.bug
From: rdonahue@spdcc.com (Bob Donahue)
Subject: Mixing eqn and ms macros
Organization: insert anything here
Distribution: gnu
Date: Mon, 14 Sep 1992 13:27:08 GMT

	With groff V1.05 I get fatal errors if I do the following:

[... lots of happy groff code]
.sp
.in .5i
.IP $lambda$
[... more stuff]

	Apparently you can't use an imbedded equation as the label
for an in dented paragraph.

	has this been fixed with V1.06?

Bob Donahue

Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: en-dash doesn't work with -TX75
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 20:10:49 GMT

GROFF VERSION: 1.06

MACHINE: Sun Sparcstation 1

OS: SunOS 4.1.2 + X11R5p17

COMPILER: GCC 2.2.2

INPUT FILES: \(en

COMMAND LINE: groff -TX75

DESCRIPTION OF INCORRECT BEHAVIOUR: groff outputs:
	warning: can't find special character `en'

SUGGESTED FIX:

===================================================================
RCS file: tmac/tmac.X,v
retrieving revision 1.6
diff -c -r1.6 tmac/tmac.X
*** tmac/tmac.X	1992/08/15 11:59:36	1.6
--- tmac/tmac.X	1992/09/15 20:04:57
***************
*** 15,20 ****
--- 15,21 ----
  .char ^ \v'-.55m'\\s[\\n(.s/2u]\v'.3m'\(ha\v'-.3m'\s0\v'.55m'
  .if !c\(va .char \(va \o'\(ua\(da'
  .if !c\(em .char \(em --
+ .if !c\(en .char \(en \-
  .if !c\(fi .char \(fi fi
  .if !c\(fl .char \(fl fl
  .if !c\(ff .char \(ff ff
From: jwpope@lookout.IT.USwc.USwest.COM (John W. Pope)
Newsgroups: gnu.groff.bug
Subject: indxbib.cc compiled under gcc 2.2
Date: 15 Sep 92 05:15:57 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I had to force the following casts upon the "fatal_signal()" function
to avoid having gcc optimize the pointers to an "auto" storage class...

  signal(SIGHUP, (void (*)(int,...))fatal_signal);
  signal(SIGINT, (void (*)(int,...))fatal_signal);
  signal(SIGTERM, (void (*)(int,...))fatal_signal);

./indxbib/indxbib.cc circa line 219

the error messages were:
indxbib.cc:218: incompatible pointer types for argument 1 of `void (* signal (int, auto void (*)(int ...)))(int ...)'
indxbib.cc:219: incompatible pointer types for argument 1 of `void (* signal (int, auto void (*)(int ...)))(int ...)'
indxbib.cc:220: incompatible pointer types for argument 1 of `void (* signal (int, auto void (*)(int ...)))(int ...)'


It makes sense that the signal handler CAN'T be passed an auto pointer... who knows what
will be put there after leaving the function...

JP
(need more info?  email me jwpope@uswest.com)
kudo's to jjc
Xref: sparky gnu.groff.bug:209 gnu.announce:122
From: jjc@jclark.com (James Clark)
Newsgroups: gnu.groff.bug,gnu.announce
Subject: groff 1.06 available
Date: 8 Sep 92 19:32:07 GMT
Followup-To: gnu.groff.bug
To: info-gnu@prep.ai.mit.edu

Groff (GNU troff and related programs) version 1.06 is now available
for anonymous ftp from prep.ai.mit.edu as pub/gnu/groff-1.06.tar.Z
(about 1340k).

Groff is written in C++, and can be compiled by a number of different
C++ compilers, including gcc/g++ 2.2 (on a sparc, at least), g++
1.40.3 and cfront 2.1.

Groff includes implementations of troff, pic, eqn, tbl, refer, the
-man macros and the -ms macros, and drivers for PostScript, TeX dvi
format, and typewriter-like devices.  Also included is a modified
version of the Berkeley -me macros, and an enhanced version of the X11
xditview previewer.  There is also an implementation of the -mm macros
contributed by Joergen Haegg (jh@efd.lth.se).

The distribution has been completely reorganized for this release.
Configuration is now automatic using a configure script built with
autoconf.  This release also includes many bug fixes and other small
improvements (see the CHANGES file for a complete description).

Please report bugs to bug-groff@prep.ai.mit.edu.

James Clark
jjc@jclark.com

      [ Soon to be at these ftp sites as well.  Please try them
	before prep.ai.mit.edu!  thanx -gnu@prep.ai.mit.edu

	Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
	Australia: archie.au:gnu
	Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
	  ftp.informatik.rwth-aachen.de:pub/gnu,
          nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
	  ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
	  ftp.diku.dk, ftp.eunet.ch, archive.eu.net
	United States: wuarchive.wustl.edu ftp.cs.widener.edu,
	  uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
	  ftp.uu.net:packages/gnu

	For information on how to order GNU software on tape, check
	the file etc/DISTRIB in the GNU Emacs distribution, or e-mail
	a request to:	gnu@prep.ai.mit.edu
      ]
Newsgroups: gnu.groff.bug