HDTenEightyP/NetNews huggingface dataset:
From: czei@musclefish.COM (Michael Czeiszperger)
Subject: built-in prototypes?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 19:42:27 GMT

Hi --

I'm trying to compile libg++-2.2 with gcc-2.2.2 on a Sun3 running
SunOS4.1.  The problem is, the compiler keeps complaining that the
prototypes in g++-includes that come with libg++ don't match the
built-in prototypes.  I've never heard of built-in prototypes, and
can't find an explanation in the docs anywhere.    I did fix the
include files after compiling gcc using "make fixincludes".

Does anyone have an idea of what's going on?

gcc -g -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
In file included from ./std.h:26, from AllocRing.cc:22:
./../g++-include/string.h:28: declaration of `long unsigned int  strlen (const c
har *)'
<built-in>:0: conflicts with built-in declaration `int  strlen (const char *)'
In file included from ./std.h:28, from AllocRing.cc:22:
./../g++-include/unistd.h:92: conflicting types for `int  geteuid (...)'
/usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/include/unistd.h:96: previous dec
laration of `short unsigned int  geteuid (...)'
./../g++-include/unistd.h:93: conflicting types for `int  getegid (...)'
/usr/local/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/include/unistd.h:95: previous dec
laration of `short unsigned int  getegid (...)'
./../g++-include/unistd.h:94: conflicting types for `int  getgid (..

Thanks awfully much for any pointers, including the much expected "you
didn't compile gcc correctly" !

Michael Czeiszperger         | "II-V-I... to me, this is a hateful progression.
Muscle Fish Consulting       |  In Jazz, they beef it up up by adding extra
czei@musclefish.com          |  partials, but its still the essense of 'bad
Berkeley, CA 94710           |  'white person music.'"  -- Frank Zappa

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: ios format flag
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 06:09:51 GMT

> According to my book, the value of fixed should be 010000 (0x1000), instead
> of 0100000 (0x8000).

Your books is wrong (or you're mis-reading it).  These flags are
arbitrary.  libg++ does not attempt to offer binary
compatibility with any other library, just source compatibility.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: iomanipulators missing?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 12:41:52 GMT

> The following manipulators seem to be missing

Yes.  They will be in the next release.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: iomanipulators missing?
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Mon, 31 Aug 1992 22:07:12 GMT

The following manipulators seem to be missing from libg++ iostreams:

setw
setiosflags
resetiosflags

There may be others. These exist in my copy of SunC++ 2.1.

Newsgroups: gnu.g++.lib.bug
From: eggers@krypton.chem.buffalo.edu (Bill Eggers)
Subject: ios format flag
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 30 Aug 1992 06:54:01 GMT

Hello There,

 While running a test program from "Teach Yourself C++" involving setf(),
I noticed that one of the ios format flags, namely "ios::fixed", is incorrectly
defined in libg++ 2.2, the most recent version I could find.

This is a copy of the flag definitions, as in streambuf.h:

 enum { skipws=01, left=02, right=04, internal=010,
           dec=020, oct=040, hex=0100,
           showbase=0200, showpoint=0400, uppercase=01000, showpos=02000,
           scientific=04000, fixed=0100000, unitbuf=020000, stdio=040000,
           dont_close=0x80000000 //Don't delete streambuf on stream destruction
           };

According to my book, the value of fixed should be 010000 (0x1000), instead of
0100000 (0x8000).  I thought I should mention it if this happens to interfere 
with any other definition.

			Bill

Newsgroups: gnu.g++.lib.bug
From: onizuka@icot.or.jp (Onizuka "Creole" Kentaro)
Subject: does it bug of ostream.form()
Organization: Institute for New Generation Computer Technology, Tokyo, Japan
Distribution: gnu
Date: Thu, 27 Aug 1992 12:38:19 GMT

I found a very interesting bug in libg++-2.2.
Machine is IRIS 4D/VGX with IRIX 4.0.1

1: 

The output of this tiny program is a little bit strange.
#include <stream.h>

main()
{
  cout << form(" %10.5f\n",21.0);
  cout << form(" %10.5f\n",20.0);
  cout << form(" %10.5f\n",21.0);
  cout << form(" %10.5f\n",20.0);
  cout << form(" %10.5f\n",21.0);
  cout << form(" %10.5f\n",20.0);
  cout << form(" %10.5f\n",21.0);
  cout << form(" %10.5f\n",20.0);
  cout << form(" %10.5f\n",21.0);
}

Output is,

   21.00000
   20.000000 <- here 
   21.00000
   20.000000 <- here 
   21.00000
   20.000000 <- here 
   21.00000
   20.000000 <- here 
   21.00000

Only when form() output 20.0, the format changes.

2:

This is another bug. Because I don't want such a dirty format above, I
changed the "cout << form()" to "printf()" then interesting accident
took place

#include <stdio.h>
#include <stream.h>

main()
{
  for(int I = 0;I<10;++I)
    {
      cout << "A";
      printf("B");
    }
}

Output of this program is,

AAAAAAAAAABBBBBBBBBB

I think everyone will expect the output below.

ABABABABABABABABABAB

or are these strangeness specification?
--
.Kentaro Onizuka .... Institute for New Generation Computer Technology ...
......................................E-mail  onizuka@icot.or.jp .........
..Mi waan mek star ship! Mi waan go Mars! Dat mi drim! .....(i) x13.(s)x3.




Newsgroups: gnu.g++.lib.bug
From: dclark@cse.ogi.edu (Dan Clark)
Subject: port to DECStation 5000 w/ Ultrix V4.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 21:04:00 GMT

Hi,
thanks for all your hard work providing us opportunities to use
more advanced software techniques even if we cannot convince our
management that it is worth looking into.  heaps of praises, etc.
now down to the nitty gritty details.
i have successfully ignored the warning messages duringthe
installation of bison-1.14 and gcc-1.40 which seems to
work ok for simple c programs.  the installation of g++-1.40.3 seemed
to go ok too.  now i am trying to get libg++-1.39.0 up and
going and ran into a problem with the //usr/include/sys/file.h
on the ultrix system.  a synopsis of the error is:
In file included from ../g++-include/sys/file.h:21, from File.cc:30:
//usr/include/sys/file.h:162: field `f_lk' has incomplete type
//usr/include/sys/file.h:290: warning: `flock' was declared `extern' and later `
static'
File.cc: In method class File &File::scan (const char *, ...):
File.cc:545: warning: unused variable `__vd_alist'
File.cc: In method class File &File::form (const char *, ...):
File.cc:561: warning: unused variable `__vd_alist'
*** Error code 1 (ignored)

have you run into this problem before and can you sugges any 
fixes?
the portion of the file.h on the ultrix system looks like:
struct  file {
      int      f_flag;          /* see below */
      short    f_type;          /* descriptor type */
      short    f_count; /* reference count */
      short    f_msgcount;      /* references from message queue */
      struct   fileops {
/*      return function arguments               */
        int    (*fo_rw)(        /* fp,uio,rw            */ );
        int    (*fo_ioctl)(     /* fp,com,data,cred     */ );
        int    (*fo_select)(    /* fp,which             */ );
        int    (*fo_close)(     /* fp                  
                 */ );
      } *f_ops;
      caddr_t f_data;           /* inode */
      off_t    f_offset;
      struct ucred *f_cred;
      struct lock_t f_lk;
};

this effects three modules:
ar: Error: File.o cannot open
ar: Error: filebuf.o cannot open
ar: Error: Filebuf.o cannot open
ar: Warning: creating libg++.a
ranlib libg++.a
ar: Warning:ignoring second definition of lmask__Fi defined in archive
ar: Warning:ignoring second definition of rmask__Fi definedin archive
ar: Warning:ignoring second definition of BSnew__Fi defined in archive

and fives the extra messages reported above.
the rest of the library seems to compile ok.

i am still limping along with C++ but hope to get rid of the major
link errors.
i have GAS but do not see that it is likely it will work for 
the MIPS chip with this machine is based on.
any advice, suggestions, good way to test things out...
thanks
dan clark 
dclark@cse.ogi.edu
503/230-4400

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: built-in prototypes?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 10:21:52 GMT

./../g++-include/string.h:28: declaration of `long unsigned int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `int  strlen (const char *)'

This is because of conflicts in the definition of size_t.
size_t is pre-defined (using the macro SIZE_TYPE) in gcc.
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).

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: LIBG++, AT&T DIFFERENCE=> filebuf: :openprot
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 12:48:13 GMT

I put it, since it is in the AT&T man pages (though it is not in the
ANSI draft).
	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: shite@sinkhole.unf.edu (Stephen Hite)
Subject: Re: Need help compiling libg++-2.2 for Esix SVR4.0.3
Organization: University of North Florida, Jacksonville
Distribution: gnu
Date: Sun, 23 Aug 1992 17:55:52 GMT

In article <1992Aug19.165447.7113@engage.pko.dec.com> balson@gauss.enet.dec.com (Jim Balson) writes:
>
>	Hi, I am having a problem compiling libg++ on a 386/Esix SVR4
>machine. The following error occurs.
>
>
>
>gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c timer.cc
>gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c math.cc

   Don't use "-g."  I'm running into problems with CursesW.cc.  There's
a problem with correctly configuring varargs for SVR4 (at least this is
what I'm experiencing).  There are others who have gotten libg++ 2.2 to
compile on Esix SVR4 though.  I don't have their e-mail addresses. :-(

Steve Hite
shite@sinkhole.unf.edu

Newsgroups: gnu.g++.lib.bug
From: onizuka@icot.or.jp (Onizuka "Creole" Kentaro)
Subject: does it bug of ostream.form()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 03:04:59 GMT

   > > The output of this tiny program is a little bit strange.
   > > Only when form() output 20.0, the format changes.
   > 
   > This was a problem in libg++/iostream/outfloat.C.
   > I've appended my curent version.  I've no idea if how
   > compatible it is with libg++-2.2.

Thank you. I will try your src on my system.

   > No.  stdout and cout are different objects, with different buffers.
   > They are not synchonized (unless you use the stdio implementation
   > in libg++/iostream/stdio - in whcih case you will get the
   > formatting bug with printf).
   > 
   > The same will happen for most implementations of iostreams.

I supposed as you said.

Thank you.

..Kentaro Onizuka .... Institute for New Generation Computer Technology ...
.......................................E-mail  onizuka@icot.or.jp .........
...Mi waan mek star ship! Mi waan go Mars! Dat mi drim! .....(i) x13.(s)x3.




Newsgroups: gnu.g++.lib.bug
From: totsuka@avaia.av.CRl.sony.co.JP (Takashi Totsuka)
Subject: libg++2.2.2 (Complex: :sqrt()) problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 00:00:40 GMT

Hello,

	This is to report a strange behavior (bug) of Complex::sqrt()
	on IRIS Crimson. Since Steve Rumsby told me at comp.sys.sgi that
	he has the same problem with his R3000/Indigo, I suspect this is not
	a particular problem of R4000/Crimson.

	Symptom:
		Complex::sqrt() returns incorrect value. Moreover, each time
		it is called with an identical argument, it returns a
		different value.  Because of this, the test program
		tComplex.cc produces wrong output.

		I played with the method and found from printf(3) output that
		the return value of hypot(3) is incorrect. However, I still
		believe	hypot(3) is correct since it works fine when I test the
		routine with a test program (under native cc and gcc2.2.2).

	Note:
		Funny behaviors I noticed are:
		(1) g++ -O  and g++ -g  yields different result.
		(2) rewriting the code to a set of simpler expressions
		    using temporary variables makes -g version works.

		From these observations, I suspect if there is any
		proc-call convention problem or instruction scheduling
		problem.


	I would appreciate your help and please let me know if I could help
	you in any way. I'll be happy to send asm source etc.


Takashi Totsuka      totsuka@av.crl.sony.co.jp
		     SONY Corporation


Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: groff 1.06 Makefile.comm forgets to remove y.output
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 20:32:49 GMT

GROFF VERSION: 1.06

MACHINE: Sun Sparcstation 1

OS: SunOS 4.1.2

COMPILER: GCC 2.2.2 with local changes

INPUT FILES: none

COMMAND LINE: none

DESCRIPTION OF INCORRECT BEHAVIOUR:
`make realclean' forgets to remove bison's y.output files.

SUGGESTED FIX:

===================================================================
RCS file: Makefile.comm,v
retrieving revision 1.6
diff -c1 -r1.6 Makefile.comm
*** Makefile.comm	1992/08/28 10:23:35	1.6
--- Makefile.comm	1992/09/02 08:06:34
***************
*** 45,47 ****
  DISTCLEANFILES=TAGS Makefile
! REALCLEANFILES=$(YTABC) $(YTABH) Makefile.dep
  NAMEPREFIX=
--- 45,47 ----
  DISTCLEANFILES=TAGS Makefile
! REALCLEANFILES=$(YTABC) $(YTABH) y.output Makefile.dep
  NAMEPREFIX=

Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: groff 1.06 nit: troff/input.cc sets char to 133
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 20:18:30 GMT

GROFF VERSION: 1.06

MACHINE: Sun Sparcstation 1

OS: SunOS 4.1.2

COMPILER: GCC 2.2.2 with local patches

INPUT FILES: none

COMMAND LINE: none

DESCRIPTION OF INCORRECT BEHAVIOUR:
groff 1.06 initializes a char variable with the value 133,
which strictly speaking isn't allowed on systems with signed chars,
where legal chars are in the range -128..127.

SUGGESTED FIX:
===================================================================
RCS file: troff/input.cc,v
retrieving revision 1.6
diff -c1 -r1.6 troff/input.cc
*** troff/input.cc	1992/08/25 15:02:53	1.6
--- troff/input.cc	1992/09/02 09:04:53
***************
*** 134,136 ****
  const int ESCAPE_E = 0204;
! const int LAST_PAGE_EJECTOR = 0205;
  const int ESCAPE_RIGHT_PARENTHESIS = 0206;
--- 134,137 ----
  const int ESCAPE_E = 0204;
! const char LAST_PAGE_EJECTOR_char = '\205'; // to avoid initialization overflow
! const int LAST_PAGE_EJECTOR = (unsigned char) LAST_PAGE_EJECTOR_char;
  const int ESCAPE_RIGHT_PARENTHESIS = 0206;
***************
*** 1810,1812 ****
    topdiv->set_ejecting();
!   static char buf[2] = { LAST_PAGE_EJECTOR, '\0' };
    input_stack::push(make_temp_iterator(buf));
--- 1811,1813 ----
    topdiv->set_ejecting();
!   static char buf[2] = { LAST_PAGE_EJECTOR_char, '\0' };
    input_stack::push(make_temp_iterator(buf));

Newsgroups: gnu.groff.bug
From: D.Parrott@cs.ucl.ac.uk (Dave Parrott)
Subject: bounding boxes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 13:35:03 GMT

is there any way of making grops produce bounding boxes for its
postscript output?

thanks,
Dave.

_______________________________  __  _________________________________
David J. Parrott ---            {~ )    Department of Computer Science
Email: D.Parrott@cs.ucl.ac.uk    | |    University College London,
Tel: +44 (0)71 387 7050 x3701     \|    Gower Street, London WC1E 6BT.
Fax: +44 (0)71 387 1397          _/|`   England.
----------------------------------- \ --------------------------------

Newsgroups: gnu.groff.bug
From: gnb@bby.COM.AU (Gregory N. Bond)
Subject: ms: Macros with the same name as fonts break .B
Organization: Burdett, Buckeridge & Young, Melbourne, Australia
Distribution: gnu
Date: Wed, 2 Sep 1992 03:09:16 GMT

			   Groff Bug Report

GROFF VERSION:
1.05

MACHINE:
Solbourne 5/601 (moral equivalent to a Sun 4/360)

OS:
OS/MP 4.1A.1, equivalent to SunOs 4.1.1

COMPILER:
gcc 2.2.2

INPUT FILES: 
(see attached shar file)

COMMAND LINE:
groff -TX100 -ms t2.ms
(same problem for -Tps etc)

DESCRIPTION OF INCORRECT BEHAVIOUR:
Defining a macro with the same name as a font (not an unreasonable
thing to do to allow customisation of documents), the groff ms macros
break the .B request.  A line like ".B text" ignores the text and
turns on bold mode.  Doesn't happen if the macro is called something
else, doesn't matter if the macro is used or not.  Doesn't happen in
the system troff, nor when using the system ms macros (i.e. 
	groff -M /usr/lib/tmac/ -TX100 -ms t2.ms
works as expected.)

Macros named .R are OK; ones named .CW or .I fail.  (I haven't checked
other font names.)

This was discovered in the man.ms file from Tom Christiansen's perl
man package.

SUGGESTED FIX [optional]:
(none)

----- cut here
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  t2.ms
# Wrapped by gnb@leo on Wed Sep  2 12:37:05 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 't2.ms' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'t2.ms'\"
else
echo shar: Extracting \"'t2.ms'\" \(96 characters\)
sed "s/^X//" >'t2.ms' <<'END_OF_FILE'
X.de CW
X..
X.PP
XHello.  This line contains some
X.B bold
Xcharacters that don't do what you expect.
END_OF_FILE
if test 96 -ne `wc -c <'t2.ms'`; then
    echo shar: \"'t2.ms'\" unpacked with wrong size!
fi
# end of 't2.ms'
fi
echo shar: End of shell archive.
exit 0
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``USL has never sold long distance.  You're going after the wrong men in black 
  hats.  (Or, in the case of Plan 9, black space suits)'' - Tom Limoncelli


Newsgroups: gnu.groff.bug
From: gnb@bby.COM.AU (Gregory N. Bond)
Subject: Query: LJ output?
Organization: Burdett, Buckeridge & Young, Melbourne, Australia
Distribution: gnu
Date: Wed, 2 Sep 1992 01:39:04 GMT

[ I realize this is a .help request to a .bug group but I couldn't see
any better groups.  Suggestions welcome. ]

groff 1.05, SunOs 4.1 on a Sparc.

Any plans for a LaserJet post filter?  Does the Chris Lewis' ljroff
work well enough with gtroff?  Any hints on seamlessly integrating
them?

TIA,

Greg.
--
Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
``USL has never sold long distance.  You're going after the wrong men in black 
  hats.  (Or, in the case of Plan 9, black space suits)'' - Tom Limoncelli


Newsgroups: gnu.groff.bug
From: jjc@jclark.com (James Clark)
Subject: bounding boxes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 09:35:26 GMT

   is there any way of making grops produce bounding boxes for its
   postscript output?

No, but there's a program called bbfig that can, in conjunction with a
PostScript interpreter, calculate the bounding box of most PostScript
documents.  You can ftp it from
saqqara.cis.ohio-state.edu:/pub/postscript/bbfig.shar.

James

Newsgroups: gnu.groff.bug
From: karl@aten.cs.umb.edu (Karl Berry)
Subject: Makefile.dep cannot be remade
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 15:22:51 GMT

I compiled and installed groff 1.06 on a Sun 4 without incident.
Then I typed `make realclean', and went to another machine.
configure ran fine, but then I got `Making all in libgroff' /
`make[2]: fopen: Makefile.dep: No such file or directory'

and Makefile couldn't figure out what to do next...

(This is GNU make 3.62 but I doubt it matters.)

karl@cs.umb.edu
From: jjc@jclark.com (James Clark)
Newsgroups: gnu.groff.bug
Subject: Makefile.dep cannot be remade
Date: 4 Sep 92 11:35:30 GMT
Distribution: gnu
Organization: GNUs Not Usenet


   I compiled and installed groff 1.06 on a Sun 4 without incident.
   Then I typed `make realclean', and went to another machine.

In this situation it's better to use `make distclean': this deletes
all the files that were created by configuring and building groff, but
doesn't delete any files that are part of the distribution.

   configure ran fine, but then I got `Making all in libgroff' /
   `make[2]: fopen: Makefile.dep: No such file or directory'

   and Makefile couldn't figure out what to do next...

Thanks.  I've modified `make realclean' not to remove the Makefile.dep
files.
Newsgroups: gnu.groff.bug
From: rpd@hera.sbi.com (Richard P. Daley)
Subject: gs can't handle postscript from macs running system 7
Keywords: macintosh,system 7
Organization: Fulcrum - Salomon Brothers, NY
Distribution: gnu
Date: Wed, 26 Aug 1992 16:45:29 GMT

I've been playing around with Ghostscript, and it works very well.  The only
problem I'm having is that it gets ill when I feed it Postscript that was
generated on a mac.  Has anyone dealt with this problem?  Is there something
I can do to Ghostscript to make this work?  Or, is there something I can
do to the Postscript to make it Ghostscript-friendly?

I'm using Ghostscript version 2.5.

Newsgroups: gnu.ghostscript.bug
From: sijon@lin.foa.SE (Sven Ingvar J|nsson)
Subject: Problem with Uniplex PS files.
Summary: Uniplex PS files cause errors with Ghostscript 2.41
Keywords: Uniplex
Organization: FOA, Linkoping, Sweden
Distribution: gnu
Date: Tue, 1 Sep 1992 14:25:17 GMT

We are using Ghostscript 2.41 under Ultrix 4.2A. When we try to convert PS
files from Unpilex (V 6.10) Ghostscript stops with the message:
  Error: /nocurrentpoint in --show--
These files are printable on PS printers with no errors. Has anybody else tried
Uniplex PS files with Ghostscript?
I tried Ghostscript 2.5 also but it was not any better.

Sven Ingvar Jonsson
E-mail:  sijon@lin.foa.se
Fax:     +46 13 131665


Newsgroups: gnu.ghostscript.bug
From: derek@hera.sbi.com (Derek Jean-baptiste)
Subject: ghostscript2.5 bug
Keywords: ghostscript, fonts, compiled in, gconfig.h,gconfig.c, iccfont.s
Organization: Fulcrum - Salomon Brothers, NY
Distribution: gnu
Date: Thu, 27 Aug 1992 14:21:38 GMT

There seems to be a bug in the unix-gcc.mak file. When I try to 
compile fonts into ghostscript I get a circular dependency between
iccfonts.c and gconfig.h.  Since this makes it immpossible to build
gconfig.h, I made it by hand in the new format but after a succesful
make of the fonts + ghostscript, ghostscript still load the fonts from
disk.  Is this a bug? Is there a work around

Derek Jean-Baptiste
derekj@zip.sbi.com

Newsgroups: gnu.ghostscript.bug