Setting GS_LIB_DEFAULT and other paths on Windows

[John Brown]

Hello All,

I have managed to compile v9.06 with MinGW/MSYS. My problem is
that initially GS_LIB_DEFAULT looked like this:

$ gswin32c --help
<snip/>
Search path:
   %rom%Resource/Init/ : %rom%lib/ : c;C :
   MinGWlocalshareghostscript9.06ResourceInit;c;C :
   MinGWlocalshareghostscript9.06lib;c;C :
   MinGWlocalshareghostscript9.06ResourceFont;c;C :
   MinGWlocalshareghostscript♀onts;C;c : MinGWmsys☺.0WindowsFonts
Initialization files are compiled into the executable.
For more information, see c:/mingw/local/share/ghostscript/9.06/doc/Use.htm.

That looked very wrong, so without going any further, I edited

./obj/gconfigd.h to look like this:

#define GS_LIB_DEFAULT "C:/MinGW/local/share/ghostscript/9.06/Resource/Init;C:/M
inGW/local/share/ghostscript/9.06/lib;C:/MinGW/local/share/ghostscript/9.06/Reso
urce/Font;C:/Windows/Fonts"
#define GS_DEV_DEFAULT "x11alpha bbox"
#define GS_CACHE_DIR "~/.ghostscript/cache/"
#define SEARCH_HERE_FIRST 0
#define GS_DOCDIR "c:/mingw/local/share/ghostscript/9.06/doc"

and ran make again.

This time:
Search path:
   %rom%Resource/Init/ : %rom%lib/ : c;C :
   /MinGW/local/share/ghostscript/9.06/Resource/Init;c;C :
   /MinGW/local/share/ghostscript/9.06/lib;c;C :
   /MinGW/local/share/ghostscript/9.06/Resource/Font;c;C :
   /MinGW/local/share/ghostscript/fonts;C;C : /Windows/Fonts

This was still not quite right, but the following command produced
a PDF without a problem:

$ bin/gswin32c.exe -sDEVICE=pdfwrite -sOutputFile=alphabet.pdf \

-dNOPAUSE -dBATCH alphabet.ps

and `strings gswin32c.exe | grep -i mingw' returned

c;C:/MinGW/local/share/ghostscript/9.06/Resource/Init;c;C:/MinGW/local/share/gho
stscript/9.06/lib;c;C:/MinGW/local/share/ghostscript/9.06/Resource/Font;c;C:/Min
GW/local/share/ghostscript/fonts;C;C:/Windows/Fonts
c:/mingw/local/share/ghostscript/9.06/doc
Mingw runtime failure:

which is what I expected, except for the repeated single-letter directory
"c", which I can easily take out of gconfigd.h.

It turned out that both executables worked, although I noticed in both
casese, they did not load the font from a directory in the search path:

Loading URWPalladioL-Ital font from %rom%Resource/Font/URWPalladioL-Ital... 2819
136 1431332 1720984 427061 2 done.

1) Is GS_LIB_DEFAULT now specified correctly?

2) Do I need to be concerned about how it is reported by `gswin32c --help'?

3) What should I do to get the right result up front, without
   having to modify gconfigd.h?

4) What should I do with "~/.ghostscript/cache/" on Windows?

Regards,
John Brown.

[John Brown]

In case anyone is interested in this, I have not solved it yet,
but I now have more insight.

I downloaded the official Windows binary and compared it with mine.
According to strings, the correct internal representation on
Windows is "Full-path1;Full-path2". The difference in display

(
official - %rom%Resource/Init/ ; %rom%lib/ ; c:/gs/gs9.06/Resource/Init ;
c:/gs/gs9.06/lib ; c:/gs/gs9.06/Resource/Font ; c:/gs/fonts

mine - %rom%Resource/Init/ : %rom%lib/ : c :
/mingw/local/share/ghostscript/9.06/Resource/Init;c :
/mingw/local/share/ghostscript/9.06/lib;c :
/mingw/local/share/ghostscript/9.06/Resource/Font;c :
/mingw/local/share/ghostscript/fonts;C : /Windows/Fonts
)

with a gap between the drive letter and the colon (:) seems
to be because of const char gp_file_name_list_separator, which
is defined a ';' or ':' depending on the platform-specific
file that is selected.

It seems that the unix files such as base/gp_unix.c and
base/gp_unifs.c are linked into the executable. Is there a
simple way to replace these with the appropriate files for
Windows? In Makefile.in, I see:
include $(GLSRCDIR)/unixhead.mak
...
include $(GLSRCDIR)/unix-aux.mak
include $(GLSRCDIR)/unixlink.mak
include $(GLSRCDIR)/unix-dll.mak
include $(GLSRCDIR)/unix-end.mak
include $(GLSRCDIR)/unixinst.mak

Does a corresponding set of Windows files exist, or
would I have to create them?

Regards,
John Brown.

[John Brown]

Hello All,

I found the thread
http://thread.gmane.org/gmane.comp.printing.ghostscript.devel/3619
in which Chris Liddell <at> artifex.com says:
"configure/make is for Unix-like systems, not for Windows."

I hope that he did not mean to say that it is unreasonable to
expect to be able to build Ghostscript by running
configure/make in MSYS. If he meant to say that Ghostscript is set
up for `configure' on POSIX systems and MSVC on Windows, I can accept
that.

The problem is that the documentation at
http://www.ghostscript.com/doc/9.06/Make.htm#MSys/Mingw clearly states
that "The configure build can be used to build Ghostscript on MSys/Mingw
systems ...". If that is not the case then the paragraph concerning
MSYS/MinGW should be corrected.

Regards,
John Brown.