SGI: Development

ghostscript 9.16

Okay, sports fans, I didn't want to do this but .... need to convert ps to pdf on a regular basis, pstill seems to have some problems with chinese fonts, ghostscript is bigger than what I want but ps2pdf does work well. Zo.

There is an older ghostscript in nekoware but we (me and the mouse in my pocket) looked through the release notes, seems like there's been some worthwhile fixes, thought I'd give the current edition a shot.

Stripped just about everything out of the configuration, that went okay.

Unfortunately, during the make process, I get this error :

Code: Select all

cc-1020 c99: ERROR File = /opt/homeboy/include/jpeglib.h, Line = 67
The identifier "JSAMPLE" is undefined.

typedef JSAMPLE *JSAMPROW;      /* ptr to one image row of pixel samples. */
^

cc-1020 c99: ERROR File = /opt/homeboy/include/jpeglib.h, Line = 656
The identifier "JSAMPLE" is undefined.

JSAMPLE * sample_range_limit; /* table for fast range-limiting */
^

2 errors detected in the compilation of "./base/jmemcust.c".
base/jpeg.mak:177: recipe for target 'obj/jmemcust.o' failed
gmake: *** [obj/jmemcust.o] Error 2

I'll keep my mouth shut since whatever I think is likely to be wrong so open the ears, close the mouth for now ... idears ? Is this possibly related to the whole libjpeg mess ?
Juliet ! the dice were loaded from the start ...
/opt/homeboy ? :P
anyway grep through your includes and see whether JSAMPLE is defined somewhere. if not you might get away with

Code: Select all

typedef unsigned char JSAMPLE;
r-a-c.de
JSAMPLE should be defined in jmorecfg.h which should be included by jpeglib.h. So make sure that somewhere near the top of jpeglib.h there's a line that reads:

Code: Select all

#include "jmorecfg.h"

Also make sure that jmorecfg.h is located in the same directory as jpeglib.h. But beware that if either of those are missing, that would indicate problems with your whole libjpeg installation....

If you're missing the definition of JSAMPLE, it makes me wonder what else will be broken. There's a lot more stuff defined in jmorecfg.h. So while I'm sure foetz's suggestion will solve the immediate problem, it might not get you much farther.

It shouldn't matter whether you're using the IJG libjpeg or libjpeg-turbo. Both seem to the same in this regard, AFAICT from a quick check of both sets of sources.
:Indigo2IMP: :Octane: :Indigo: :O3x0:
Sun SPARCstation 20, Blade 2500
HP C8000
foetz wrote: anyway grep through your includes and see whether JSAMPLE is defined somewhere. if not you might get away with

Code: Select all

typedef unsigned char JSAMPLE;

I kinda went through something related to this when I made jpeg-turbo. There was a configuration switch to "enable 12 bit depth" which I thought, "Oh cool, let's add that."

Wrong-o :( Jpeg can be either 8-bit or 12 bit but not both. So suddenly all my jpegs disappeared.

Rebuilt it as 8-bit, they all came back.

A little bit about that :

http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG

Back on the subject,

jmorecfg

Code: Select all

typedef char JSAMPLE;
#ifdef __CHAR_UNSIGNED__
#define GETJSAMPLE(value)  ((int) (value))
#else
#define GETJSAMPLE(value)  ((int) (value) & 0xFF)
#endif /* __CHAR_UNSIGNED__ */


jpeglib

Code: Select all

/* Data structures for images (arrays of samples and of DCT coefficients).
*/

typedef JSAMPLE *JSAMPROW;      /* ptr to one image row of pixel samples. */
typedef JSAMPROW *JSAMPARRAY;   /* ptr to some rows (a 2-D sample array) */
typedef JSAMPARRAY *JSAMPIMAGE; /* a 3-D sample array: top index is color */

typedef JCOEF JBLOCK[DCTSIZE2]; /* one block of coefficients */
typedef JBLOCK *JBLOCKROW;      /* pointer to one row of coefficient blocks */
typedef JBLOCKROW *JBLOCKARRAY;         /* a 2-D array of coefficient blocks */
typedef JBLOCKARRAY *JBLOCKIMAGE;       /* a 3-D array of coefficient blocks */

typedef JCOEF *JCOEFPTR;        /* useful in a couple of places */

...

JDIMENSION total_iMCU_rows;   /* # of iMCU rows in image */
/* The coefficient controller's input and output progress is measured in
* units of "iMCU" (interleaved MCU) rows.  These are the same as MCU rows
* in fully interleaved JPEG scans, but are used whether the scan is
* interleaved or not.  We define an iMCU row as v_samp_factor DCT block
* rows of each component.  Therefore, the IDCT output contains
* v_samp_factor*DCT_[v_]scaled_size sample rows of a component per iMCU row.
*/

JSAMPLE * sample_range_limit; /* table for fast range-limiting */


I dunno ... looks like it's there :(

jpstewart wrote: JSAMPLE should be defined in jmorecfg.h which should be included by jpeglib.h. So make sure that somewhere near the top of jpeglib.h there's a line that reads:

Code: Select all

#include "jmorecfg.h"

Code: Select all

#ifndef JCONFIG_INCLUDED        /* in case jinclude.h already did */
#include "jconfig.h"            /* widely used configuration options */
#endif
#include "jmorecfg.h"           /* seldom changed options */


Also make sure that jmorecfg.h is located in the same directory as jpeglib.h.

Yes.

But beware that if either of those are missing, that would indicate problems with your whole libjpeg installation....

Seems to be all there ?

If you're missing the definition of JSAMPLE, it makes me wonder what else will be broken.

Seems to be there, so I'm wondering why this seems to be broken :D

As an added point, I've built several programs on top of this libjpeg (Graphics Magick is one, manipulates jpegs fine) so it's not as if this is a veergin install, never been sampled. Also adopted the habit of running gmake check on everything now, but I don't remember if turbo-jp had any tests :(
Juliet ! the dice were loaded from the start ...
well then it might not be able to find the include
r-a-c.de
the continuing adventures of creating pdf's under Irix ...

In case anyone ever comes along who wants to make pdf's in Irix : somebody famous said "Life's wide, there's room enough to back up and take another run at it ..." so that's what we did.

neko_ghostscript 8.51 worked for me in the past. So I grabbed the release notes (thank you, voidfoo). Backed off optimization to -O1. It built, as I hoped. Almost said "as expected" but them days are long gone.

Still had problems with building pdf's, and I know it worked when we ran win2k on the Box of Doom, so ditched the PostScript driver we were using on Winders and got one directly from Adobe. They invented it, so they should have a reliable print driver, yes ?

pstill still kacks but now ps2pdf can at least create vanilla pdf's. Not sure why there are still font problems with 8.51, it worked before, but may as well row upstream while investigating : there's an 8.71 in nekoware but it has cups and a lot of other things I don't want so, build from scratch !

Kept the -O1 optimizing flag. ./Configured --without-stupid-crap. gmaked ...

Code: Select all

cc-1117 c99: ERROR File = ./base/gsnogc.c, Line = 35
An expression appears after a "return" in a "void" function.

return gs_free_object(mem, str, cname);
^

in three or four different places. Jeeze.

Did the foetz trick (thank you foetz) and made that

Code: Select all

gs_free_object(mem, str, cname);
return;


Don't they have any rules for this shit ? If I had these little idiots writing APT programs I'd scare the crap right out of their little drawers ... you do not do shitty code when it drives a machine.

Tangent : I was the house honky in a joint venture in dongbei. It was a flaky joint venture like all of them but kinda fun. The 'partners' already knew everything, of course, because they had these Roosky tube-driven controls. We brought in some K&T's from a McDonnell-Douglas auction (the US made decent stuff, once upon a time. And we had a middle class, too. Hard to believe now ...) Kick Roosky ass all day long, then go kick Jap ass at night :D K&T D controls, nice controls, better than anything they sell today.

My lads were like Chinese everywhere, they don't believe in checking anything. Kind of like the dipshits writing Loonix software. I'm forcing them to single-block through the first run of a new program, and I can see there's a massive error a few blocks ahead. They never listen to me so it's time for a little payback. The part is a transmission housing for a small car, mounted on an angle plate, next step was a 2" drill that was supposed to rapid up to .1" away from the part, then drill.

Except someone misplaced a minus sign.

So I casually stepped back a few paces, asked if they were sure, "Of course we're sure ! We wrote this program ! We're stars !" zooo I said, "okay, poosh dee button then" and kind put my hand in front of my face cuz when 8,000 lbs of column drives a 2" drill right through a part and an inch-thick angle plate at 400 inches per minute, the resulting destruction will get your attention.

I don't think they liked me after that :P

Anyway, with these errors corrected, 8.71 builds. Not sure why pstill doesn't like the Word-Acrobat-produced postscript files but ps2pdf now functions ... inspired by the wreck :
colortest.pdf
(120.81 KiB) Downloaded 6 times

Chinese fonts still blow it up but we're making progress.

I also notice that the whole font things is ... peculiar. The test part was a Word doc using some strange-ass font, on purpose. Somehow that got substituted into Arial. Hunh ? I thought postscript was supposed to embed any strange fonts that weren't part of the base set ?

btw, tried 9.05 (tons of errors) and 9.16 (same), put them aside for the moment while I struggle with double-byte fonts. For the moment, 8.71.1 is mostly functional. But we shall return :P
Juliet ! the dice were loaded from the start ...
^ bump. Dumped the previous reply because it was no longer accurate. ^
Juliet ! the dice were loaded from the start ...
So I'm maybe not the dumbest person on the planet (you can tell that because I'm not running for president) but close. Real close.

The good part is, ghostscript 8.71.1 builds easily with MIPSPro - at least, if you aren't loading up with cairo, cups, and all that other crap. And it creates pdf's easily. Does a nice job, too.

The part that had me tearing out my hair was if the pdf had Chinese fonts, the viewer would segfault and crash immediately. So I'm stupidly wasting my time with libiconv, libintl, all that crap. I thought ps2pdf was having a problem mapping that font to something it could use.

Umm, when I opened the test pdf on Windows, it was perfect :(
font-test.pdf
(47.71 KiB) Downloaded 5 times


Dumbass. Xpdf was crashing because it couldn't find a suitable font to use. The pdf was fine. It does seem as if xpdf could find a nicer way to warn you that a font is not available, however.

The good news for Irrixxers is, ghostscript 8.71.1 is easy to build. You have to set it to -O1, other than that, no problems (no cairo, no cups, and much of the other stuff disabled here tho. I don't use jbig or that other dick-waving junk.)

Yay ! We will return to 9.16 later. For now, time to bask in unearned success :D
Juliet ! the dice were loaded from the start ...
nice, seems you're getting the hang of it more and more :D
r-a-c.de
foetz wrote: nice, seems you're getting the hang of it more and more :D

Thanks for the compliment, but I'd rather hit cows in the head with a sledge hammer ! This kinda sucks. Every step is a battle ...

Here's a wrapup, if there's ever anyone else out there who wants to create pdf's within Irix, a little free data for your viewing pleasure :

Adobe never made a Distiller for Irix. They made one for Sun and AIX but we got left on the doorstep in a basket.

Pstill worked for me but crashed if I tried to use Chinese fonts. It converted the demo files okay and maybe could have been tweaked to do dbcs or maybe it was just me. But I had already used ps2pdf a lot and it works well.

If you are happy with a waddling welfare Octane (she's one of the Butt sisters), then just grab ghostscript 8.51 from nekoware. It works.

I have personally been happy with an Octane free of the layer upon layer of klugey stuff added since 6.5.22. It's a lot of work but makes a much nicer computer. So this is what I did :

Ghostscript 8.71.1 builds right off the bat, no tricks needed. The main point is to set optimizing to -O1. This is what I used, plain-jane, shamelessly stolen from canavan

Code: Select all

setenv CC c99
setenv CFLAGS '-O1 -mips4 -DIRIX -I. -I/opt/homeboy/include'
setenv CXXFLAGS '-ptused -DIRIX -O1 -mips4 -I. -I/opt/homeboy/include'
setenv LDFLAGS '-L/opt/homeboy/lib -L/usr/lib32 -lm -rpath /opt/homeboy/lib'

Any criticisms of the environment are appreciated ...

then a configure, much of this I don't have but just in case, we disabled it anyhow

Code: Select all

./configure --prefix=/opt/homeboy --disable-contrib --disable-fontconfig --disable-cups
--disable-gtk --disable-cairo --without-libpaper --with-system-libtiff --without-pdftoraster
--without-ijs --without-jbig2dec --without-jasper --without-omni --disable-debug


I initially tried to restict the printer drivers - I don't own an Office Depot, drivers for every printer ever born aren't useful to me - but linking failed when I tried that. Since these are going to go away later anyhow, I surrendered, Dorothy. Try it at your own risk.

From this point it builds fine with MIPSPro 7.4.4. Probaly earlier ones too but I don't have an earlier one.

Did gmake install, then here's the trick part : you can go into /opt/homeboy/share/ and delete everything under ghostscript. It will still create pdf's. It will still create pdf's with Chinese fonts :D And you won't have a bunch of phony pseudo-fonts cluttering up your computer. Or sudo-fonts, if you're a pseudo-Unix kinda guy/gal :P

There's some useless scripts in /bin, too. And a bunch of paths that don't exist in the main ghostscript executable. Maybe drag out the hex editor later ... or wait, there's another configure switch to try ... maybe another day.

Ran tests, pdf's so far seem good. Ghostscript alas does not have a < gmake uninstall >. Also, < gmake check > runs through whatever routine it has but reports nothing. If these guys built bridges I'd swim.

One further check, built mgv (motif ghostscript viewer) with no problems after the ghostscript flab removal operation. And , the odd thing is, it displays the chinese font test which < showps > complains about.

I need to install some CID dbcs font or another later, but for now, this is okay. xpdf segfaults if it can't find a suitable font but our customers all use Windows so I'm safe for now.

Maybe 9.16 some time in the future.

Oh. Attached is the Adobe ppd file which they suppply for Windows. They call it Distiller. I'm thinking of installing it under Impressario for creating plain ps files. I'm not that confident that a specific printer's ppd is the best way to create universal postscript files ... had to hunt for this sucker for an hour, so hope this saves someone some grief.
distiller-ppd.zip
(3.9 KiB) Downloaded 5 times

That's enough computing for this week. Hope y'all have a loverly Sunday :D

edit: Oh wait - I lied. 8.71.1 requires the foetz-fixes above. But they are documented earlier in the thread. It's a simple edit to four or five files. Brain-failure :(
Juliet ! the dice were loaded from the start ...
hamei wrote: The main point is to set optimizing to -O1. This is what I used, plain-jane, shamelessly stolen from canavan

what happens if -O2 or higher is used?

Code: Select all

setenv LDFLAGS '-L/opt/homeboy/lib -L/usr/lib32 -lm -rpath /opt/homeboy/lib'

Any criticisms of the environment are appreciated ...

okay since you asked i can deliver 3 :P

  • you never need to add /usr/lib32 for n32 builds unless you explicitly disabled use of the standard libs. but then you don't want /usr/lib32 of course so adding -L/usr/lib32 makes no sense. if you should encounter api mismatch problems when linking use -n32.
  • -lm is hardly ever needed unless the program was made for an os that has no separate math lib which is rare. otherwise -lm works pretty much everywhere. however you might wanna add -lfastm instead.
  • -rpath is a nasty fellow because it renders the whole concept of environment variables void. only use that if you're sure that the user(s) don't mind the program using enforced paths. account/environment customizations are greatly limited by that.
r-a-c.de
foetz wrote: what happens if -O2 or higher is used?

You are a bad influence ...

Code: Select all

Signal: Segmentation fault in Global Optimization -- Second rename phase.
Error: Signal Segmentation fault in phase Global Optimization -- Second rename -- processing aborted
c99 ERROR:  /usr/lib32/cmplrs/be died due to signal 4
c99 ERROR:  core dumped
base/lib.mak:620: recipe for target 'obj/gxfill.o' failed
gmake: *** [obj/gxfill.o] Error 32

Another run-through did inspire me to try a couple more things ... if you allow it to build the init scripts into the executable, then you don't need that honkin' big directory of mostly-useless scripts. So lose a little, save a fair amount. And I ditched all but two or three printers - I figured it might get pissed if there was no output device, so I picked a plain old Laserjet and IBM Proprinter, those are minimal and pretty standard. Dropped the path way back to JUST the real SGI fonts (and even there I ditched Amie, Laura, Rock, Cave, that other shit that no one anywhere has ever used.) 400 fonts just means you have to paw your way through ten pages of lists to find the one you want. No normal human needs 400 fonts.

Built again at -O1, still working.

I don't know why I bother with gmake check. I hope at least if it crashes it will say something.
okay since you asked i can deliver 3

Thanks, I should ditch those I guess ... they crept in as solutions to some particular problem, then never crept out again. It's probably better just to use them when needed, hunh ? :oops:

Onward and upward !

edit: Okay, I had to change one more thing. The "ProductName" is now "Irix Ghostscript". We have just as much right to claim it as gnu does, Artifex actually wrote the thing :P
Juliet ! the dice were loaded from the start ...
hamei wrote:

Code: Select all

Signal: Segmentation fault in Global Optimization -- Second rename phase.
Error: Signal Segmentation fault in phase Global Optimization -- Second rename -- processing aborted
c99 ERROR:  /usr/lib32/cmplrs/be died due to signal 4
c99 ERROR:  core dumped
base/lib.mak:620: recipe for target 'obj/gxfill.o' failed

oookay gxfill has some issues but that doesn't mean you have to build everything at -O1
r-a-c.de
foetz wrote: oookay gxfill has some issues but that doesn't mean you have to build everything at -O1

Yah, but this is an interim step. Eventually I'd like to go with 9.16. Or whatever they're up to by the time I get there. So fighting the smaller points here is sort of a waste.

I'm happy as a clam that this works tho. Creating pdf's is pretty much essential these days. Thanks for the assistance :D

Oh. Something to make us feel better (schadenfruede ?) -- attaching a shared file from a remote server crashes Windows Firefox. Boom ! gone kerplowie. Repeatably :P
Juliet ! the dice were loaded from the start ...