Subject: gs 3.53 and up

From: [email-masked] (Ervin D. Walter)
Date: Thu, 15 Aug 1996 23:41:22 -0500

I have had a problem using ghostscript verisons 3.53 up through 4.00
in the standard distributions.  Specifically, when I try to use gs
with *any* device be it the console, X, or a printer, I get errors
like the following with the standard distribs and compiled versions:

Error: /limitcheck in --moveto--
Operand stack:
   1   0   0   0
Execution stack:
   %interp_exit   ()   --nostringval--   --nostringval--
--nostringval--   false   --nostringval--   --nostringval--
--nostringval--   --nostringval--
Dictionary stack:
   --dict:645/653--   --dict:0/20--   --dict:42/200--
--dict:117/250--
Current allocation mode is local
Current file position is 311980

Now, the wierd parts.  First, these errors don't occur every time, and
they don't occur in the same place every time.  Second, the exact save
.ps file sent through gs 2.whatever or gs >= 3.53 *compiled with
optimizations turned off* works perfectly.  This evidence leads me to
believe that there is nothing wrong with my postscript source (not
that I wrote it by hand.  I came straight from dvips.).  I have solved
the problem personally by downloading gs 4.00 and compiling it with no
gcc optimizations.  However, I have to install it in /usr/local/
because I didn't have a functioning debianized version.  This means I
either have to keep a broken gs 3.x or working gs 2.x installed in
/usr/bin or I have to deal with dependency problems because dpkg
doesn't know I have gs installed in /usr/local.

What I am looking for is one of the following (in order of
preference):

1.  A debianized gs 4.0 with the problem solved so that everything is
hunky dory (sp?).

2.  A debianized gs >= 3.x with the problem solved.

3.  A debianized version of gs 4.0 with optimizations turned off
(not the best choice).

4.  A debianized version of gs >= 3.x with optimizations turned off
(beggers can't be choosers).

If any of these can be mainstreamed, even better.

Please help me if you can?  I am willing to give you any more
information that you want.  

P.S.  I did try the recommended bug-search algorithm with gs 4.0 to no
avail.

Thanks,
Ervin Walter
[email-masked]

-- 
                                  ,,,
                                 (o o)
-----------------------------oOOo-(_)-oOOo-----------------------------
Different all twisty a of in                         - [email-masked]
maze are you, passages little.              - [email-masked]

PGP Key fingerprint =  A5 AB 25 7D 7A FD 4D FE  BE 21 47 60 0C DC 67 9E

---

From: Kevin M Bealer <[email-masked]>
Date: Fri, 16 Aug 1996 05:37:55 -0400 (EDT)

> either have to keep a broken gs 3.x or working gs 2.x installed in

TeXtpert I'm not, but; [ This is only a guess ]

Turning off the optimizations and getting _any_ kind of
different end results, except for a speed or size difference
should probably be considered a bug in gcc.

That having been said, you do know there are two different "gs"
interpreters?  gs is an Alladin product, donated to GNU
(accord. to the Printing HOWTO).  As such, the GNU version is
just an older Alladin version, presumably the newer Alladin
version has more features, and different bugs.

So if you have source from one and a binary from the other, you
may be hunting bugs that are no longer with us...

> P.S.  I did try the recommended bug-search algorithm with gs 4.0 to no

? ... you mean trying to find the "bad patch?" by walking thru
the versions?

> [email-masked]

[email-masked]/GNU__1.1___Linux__2.0.12___
Programming is always harder than doing the same task manually.
It's hard because you must completely understand the problem,
take everything into consideration, and protect against every
possible flaw.  Then you never have to do it manually again. 
The great driving force behind programming is the fervent
devotion to laziness:  you wage a war to save typing later.

---

From: [email-masked] (joost witteveen)
Date: Fri, 16 Aug 1996 12:28:57 +0200 (MET DST)

> > [...]
> > 3.53 *compiled with

Or some other flaky stuff: My Cirix 486 used to play that trick
with me with gs-2.61. Also, I've seen programmes that compare
doubles: the result depends on the optimisation, as without optimisation,
all compares are done at "double" precision, but with optimisation,
sometimes the doubles are still in the FPU, and then the compare
happens at "extended" (80 bits) precision. Not a gcc bug.

> may be hunting bugs that are no longer with us...

The latest GNU version is (AFAIK) 3.33. As his problems are
with gs 3.53 and up, he can only be using Alladin version.

-- 
joost witteveen
            [email-masked]
          [email-masked]
--
Use Debian/GNU Linux!

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Fri, 16 Aug 1996 10:12:03 -0400

Hi Ervin --

You said:
> in the standard distributions.  
...
> I have solved the problem personally by downloading gs 4.00 and 
> compiling it with no gcc optimizations.  However, I have to install 
> it in /usr/local/ because I didn't have a functioning debianized version.  
> This means I either have to keep a broken gs 3.x or working gs 2.x 
> installed in /usr/bin or I have to deal with dependency problems because 
> dpkg doesn't know I have gs installed in /usr/local.
> 

I think dpkg has a mechanism for getting around this, but I've never
tried it, so beware of the following advice.

The program I think you need is called dpkg-divert.
Documentation is provided by invoking it with the --help option, and also
in the file /usr/doc/dpkg/programmer.html/ch-diversions.html (I'm referring
to dpkg version 1.3.5).  The 1.2 versions of dpkg had a file called 
/usr/doc/dpkg/diversions.text.

Good luck,
Susan Kleinmann

---

From: Ian Jackson <[email-masked]>
Date: Sat, 24 Aug 96 18:23 BST

Ervin D. Walter writes ("gs 3.53 and up"):
...
> optimizations turned off* works perfectly.
...

A new GCC was released by the FSF recently.  One of the reasons they
gave was that it could miscompile ghostscript.  ITYSBT.

Ian.