[Info-vax] Ghostscript's GenericResourceDir on OpenVMS

[Michael Unger]

[cross-posted to "comp.os.vms" ("Open" is a silent prefix) as well, no
"follow-up-to" set (intentionally) ...]

Knowing nearly nothing about GhostScript but at least a bit about
(Open)VMS ...


On 2010-01-21 15:29, "Chad" wrote:

> [...]
> 
> From wikipedia (article on files-11) a path in vms is this:
> NODE"accountname password"::device:[directory.subdirectory]
> filename.type;ver
> 
> though a number of those bits are optional.

"node name" and "access credentials" as well as the "version number" are
usually omitted.

> One thing it leaves out is that directories can be nested when one is
> declared to be "rooted", but only 1 deep.  Example:
> 
> device:[foo]bar.txt             // Fine, it is like C:\foo\bar.txt in
> Windows.
> device:[foo.baz]bar.txt         // Fine, it is like C:\foo\baz\bar.txt
> in Windows.
> device:[foo.][baz]bar.txt       // Fine, [foo.] is "rooted"
> device:[foo.][baz.][bar]qux.txt // Error.  Strangely, rooted
> directories don't nest into each other.

You _may_ need to define a "logical name" for the "rooted device" yourself:

|  $ DEFINE /SYSTEM /EXECUTIVE_MODE -
|    gs_device -
|    disk:[dir.subdir.subsubdir.] -
|    TRANSLATION=(CONCEALED, TERMINAL)

Note the ".]" at the end of the third line and the translation attribute
"concealed" in the fourth line of the definition.

The "root directory" is "GS_DEVICE:[000000]", the "examples" directory
would then be written as "GS_DEVICE:[EXAMPLES]", the "eps" subdirectory
"GS_DEVICE:[EXAMPLES.EPS]", and a file therein could be
"GS_DEVICE:[EXAMPLES.EPS]RECTANGLE.EPS".

Note: File and directory specifications may differ depending on the file
system used ("ODS-2", the "traditional one", vs "ODS-5").

> For these reasons merging paths on VMS is not as simple as just
> concatenating a bunch of stuff together.
> 
> And yeah, the gs definition is correct.  It is definitely running.  It
> is even finding its init files (it runs gs_res.ps).  But somehow what
> happens later makes it crash.
> 
>> You should probably look at /gs/base/gp_vms.c
>> gs_file_name_check_separator()
>>
> 
> I took a look at it.  Also had a look at gp_file_name_combine.
> Nothing obvious from the first few minutes of staring, so I'd probably
> have to trace through and debug the code to learn anything useful.
> I'm going to have to pass on that for now ;)
> 
>>
>>
>>
>>
>> > =====
>> > I then discovered the -sGenericResourceDir=... switch and started
>> > playing with that. Now I can change the kind of error message I get,
>> > but I still can't make it work.
>>
>> > Here are a few things I tried, with their corresponding error
>> > messages:
>>
>> > =====
>> > $ gs "-sGenericResourceDir=_DKB1:[GHOSTSCRIPT_8_70.RESOURCE." -
>> >      "-dNODISPLAY" "-sDEVICE=pdfwrite" "-sOutputFile=HTML_ORDER.pdf"
>> > HTML_ORDER.ps
>>
>> > gives
>>
>> > GPL Ghostscript 8.70 (2009-07-31)
>> > Copyright (C) 2009 Artifex Software, Inc.  All rights reserved.
>> > This software comes with NO WARRANTY: see the file PUBLIC for details.
>> > Unrecoverable error: stackunderflow in pop
>> > Unrecoverable error: undefined in .uninstallpagedevice
>>
>> This 'probably' relates to the fact that '[' and ']' have meaning in
>> PostCript, though its a bit hard to be sure.
>>
> 
> Yeah, I looked at the bit in gs_res.ps that crashed it in a couple of
> those instances, though I can't quite tell what is going on.
> Postscript is quite new to me.  Maybe there is some error in the
> parser's precedence?
> 
>> > The command I used to compile ghostscript is this:
>> > mmk/descrip=[.base]openvms.mmk/macro=(IEEE=1)
>>
>> > The compiler is DECC 7.3 and mmk is version 4.1
>>
>> > Note that I had to change a few things to make it compile:
>> > - In [.psi]int.mak I had to change PSINIT=$(PSRESDIR)$(D)Init$(D) to
>> > PSINIT=[.RESOURCE.INIT] because it wasn't assembling the path
>> > correctly.  $(D) is empty on OpenVMS so it would give [.RESOURCE]INIT
>> > instead of [.RESOURCE.INIT]
>> > - In [.jbig2dec]snprintf.c I had to comment out the #include <param.h>
>> > because param.h doesn't exist.
>>
>> That inclusion is wrapped like this:
>>
>> #ifdef __VMS
>> #include <param.h>
>> #else
>> #include <sys/param.h>
>> #endif
>>
>> So where does OpenVMS keep its param.h ? Seems likely that __VMS should
>> be defined in which case its expecting to find param.h in the usual
>> compiler directory.
>>
> 
> I don't know where it keeps that because my system seems to lack it
> entirely and Ghostscript didn't bring its own.
> 
> So I did this:
> 
> #ifdef __VMS
> //#include <param.h>
> #else
> #include <sys/param.h>
> #endif
> 
> There were no complaints about undefined symbols.  It seems like
> param.h is quite extraneous here.  All it was doing was breaking my
> build.
> 
>> > - In [.jbig2dec]snprintf.c I had to turn the implementations of
>> > snprintf and vsnprintf into mere declarations because these functions
>> > already exist in the system libraries.  Having these extra
>> > implementations around caused linker errors due to the duplicate
>> > symbols.
>>
>> Hmm well that's a bit more tricky and probably build related. If the
>> system includes those definitions then I don't think the build system
>> should be compilign and including snprintf.c.
>>
> 
> Yes, but it does.  The OpenVMS build system doesn't seem to have a
> configure phase like on unix/linux platforms.  It's just mmk make
> files.  I suspect HP probably added these into the C runtime without
> the gs devs noticing it.  Maybe no one with a newer system has both
> tried and said anything.  If it can be determined what version this
> happened in, then the gs devs could do something like this:
> http://unix.derkeiler.com/Newsgroups/comp.os.vms/2007-01/msg00659.html
> (Note: CRTL = C RunTime Library)
> 
>> But neither of these relate ot your problem.- Hide quoted text -
>>
>> - Show quoted text -

Michael

-- 
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.