make.txt

实现并行算法

request the following patches:
	Patch i.d.      Description
	100512-02       4.1.x OpenWindows 3.0 libXt Jumbo patch
	100573-03       4.1.x OpenWindows 3.0 undefined symbols when using
				shared libXmu
    Solaris
    -------
	Solaris 2.2 may require setting EXTRALIBS=-lsocket.
	Solaris 2.3 and 2.4 seem to require EXTRALIBS=-lnsl -lsocket.
	Solaris 2.n uses /usr/openwin/share/include for the X11 libraries
rather than /usr/local/X/include.
	Solaris 2.n typically makes Type 1 fonts available in
/usr/openwin/lib/X11/fonts/Type1/outline.
	For Solaris 2.n, you will need to change the definition of INSTALL
in the makefile from install -c to /usr/ucb/install -c, since the Solaris
version of 'install' requires
		install -c <directory> [-m <mode>] <file>
rather than
		install [-c] [-m <mode>] <file> <directory>
	You may need to set XLIBDIR to the directory that holds the X11
libraries, as for other SVR4 systems.  You should also set -DSVR4 in CFLAGS.

SVR4 Unix platforms:
	You may need to set EXTRALIBS=-lnsl.
	Do *not* change PLATFORM=unix_ to PLATFORM=sysv_.
	On SVR4 Unix platforms that use dynamic linking, you may need to
define XLIBDIR as the name of the directory that holds the X Windows
libraries.  Do *not* prefix this with -L.
	For SVR4.0 systems, set -DSVR4 -DSVR4_0 in the makefile; do *not*
set -DSYSV.  For SVR4.2 (or later) and Solaris 2.x systems, set -DSVR4 only
(not -DSVR4_0 and not -DSYSV).

System V Unix platforms:
	If you are using a stock System V platform that lacks rename
and gettimeofday, change PLATFORM=unix_ in the makefile to
PLATFORM=sysv_.
	You will probably need to change the definition of INSTALL (near
the beginning of the makefile) from install to /usr/ucb/install.

VAX with Ultrix:
	The above information about DECStations with Ultrix may be
applicable.

********
******** How to build Ghostscript from source (OS/2 version) ********
********

The relevant makefile is:
	os2.mak
The EMX/GCC 0.9b compiler and the IBM NMAKE.EXE are required.

Before compiling or linking, you should execute
	copy os2.mak makefile
Then to start the make process type
	nmake
One DLL and two EXE's will be produced: gsdll2.dll (Ghostscript DLL),
gsos2.exe (Ghostscript) and gspmdrv.exe (the Presentation Manager 
display driver).  

********
******** How to build Ghostscript from source (VMS aka OpenVMS version) ****
********

The files VMS-CC.MAK, VMS-GCC.MAK, and VMS-DECC.MAK are OpenVMS DCL command
files which build Ghostscript from scratch using, respectively, the VAX C
compiler, CC, the Free Software Foundation's GNU C compiler, GCC, or the DEC
C compiler, CC.  Accordingly, you must have one of these compilers installed
in order to build Ghostscript.  (Other C compilers may work: CC and GCC are
the only two compilers tested to date.  DEC C V4.0 or later is required: the
DEC C V1.3 run-time library has bugs that prevent Ghostscript from working.)
These command files build and store the Ghostscript library in the object
library GS.OLB.  If you have DECwindows (X11) installed on your system, the
executable image GS.EXE will also be built.

Some environments use the DWTLIBSHR library for providing the X Windows
intrinsics, and some use the XTSHR library.  XTSHR is newer, and is part of
the DECwindows/Motif product.  However, DEC is still distributing versions
of VMS with DWTLIBSHR.  If your environment uses XTSHR, replace DWTLIBSHR in
the list of link libraries with XTSHR.

Many versions of DEC's X server have bugs that produce broad bands of color
where dither patterns should appear, or characters displayed white on top
of black rectangles or not displayed at all.  If this happens, please
consult the X Windows section of the use.txt file to find out how to work
around these bugs using X resources; also report the problem to DEC, or
whoever supplied your X server.

You may also wish to turn off the use of a backing pixmap with Ghostscript,
either to work around X server memory limitations or bugs, or to obtain
faster displaying at the expense of no redrawing when a Ghostscript window
is restored from an icon or exposed after being occluded by another window.
Again, use.txt contains information on how to do this.

For OpenVMS VAX platforms with VAX C, issue the DCL command
	$ @VMS-CC.MAK
to build Ghostscript.  For OpenVMS platforms with GNU C (either AXP or
VAX), issue the DCL command
	$ @VMS-GCC.MAK
to build Ghostscript.  For OpenVMS platforms with DEC C (either AXP or
VAX), issue the DCL command
	$ @VMS-DECC.MAK
to build Ghostscript.

The option "DEBUG" may be specified with either command file in order to
build a debuggable Ghostscript configuration; e.g.,
	$ @VMS-CC.MAK DEBUG

In order to specify switches and file names when invoking the interpreter,
define GS as a foreign command:
	$ GS == "$disk:[directory]GS.EXE"
where "disk" and "directory" specify the disk and directory where Ghostscript
is located.  For instance,
	$ GS == "$DUA1:[GHOSTSCRIPT]GS.EXE"
To allow the interpreter to be run from any directory, define the logical
GS_LIB which points to the Ghostscript directory
	$ DEFINE GS_LIB disk:[directory]
This allows Ghostscript to locate its initialization files stored in the
Ghostscript directory -- see use.txt for further details.  Finally, to
invoke the interpreter, merely type GS.  Although DCL normally converts
unquoted parameters to upper case, C programs receive their parameters in
lower case.  That is, the command
	$ GS -Isys$login:
passes the switch "-isys$login" to the interpreter.  To preserve the
case of switches, enclose them in double quotes; e.g.,
	$ GS "-Isys$login:"

If you add compiled fonts to your system as described in the fonts.txt file,
then add the font source file names to MODULES.LIS, add "ccfonts.dev" to the
FEATURE_DEVS symbol in VMS-CC.MAK, VMS-GCC.MAK, or VMS-DECC.MAK,
	$ FEATURE_DEVS = "level2.dev ccfonts.dev"
and then specify the font names with the ccfonts1 symbol
	$ ccfonts1 = "Courier Courier_Oblique Courier_Bold Courier_BoldOblique"
If the line gets too long, add another line of the same form, e.g.,
	$ ccfonts1 = "Courier Courier_Oblique Courier_Bold Courier_BoldOblique"
	$ ccfonts2 = "Times_Roman Times_Italic Times_Bold Times_BoldItalic"

********
******** Other environments ********
********

QNX
---

The following notes are from John "Stosh" Muczynski, <[e-mail]>.
He is willing to answer questions as his time permits.  He used the Watcom
C16 compiler, version 9.5, with QNX version 4.20B.  He had to modify the
following files:

SYS/PARAM.H
Watcom doesn't supply a sys/param.h file.  I defined it as
--------------------------------clip here 
------------------------------
/* CLK_TCK is used with the times() function and is defined in times.h 
*/
#define HZ (CLK_TCK)
--------------------------------clip here 
------------------------------
It seems that HZ should be 1000 for QNX and not 100.  The times() 
function appears to be POSIX 1003.1



UNIXHEAD.MAK
I modified unixhead.mak to support a qnx_ platform.
--------------------------------clip here 
------------------------------
PLATFORM=qnx_
--------------------------------clip here 
------------------------------


UNIXTAIL.MAK
I modified unixtail.mak to support a qnx_ platform.
--------------------------------clip here 
------------------------------
# QNX 4.X
qnx__=gp_nofb.$(OBJ) gp_unix.$(OBJ) gp_qnx.$(OBJ) gp_qnxfs.$(OBJ) 
gp_unifn.$(OBJ)
qnx_.dev: $(qnx__)
	$(SETMOD) qnx_ $(qnx__)

gp_qnx.$(OBJ): gp_qnx.c $(time__h) $(AK)

gp_qnxfs.$(OBJ): gp_qnxfs.c $(AK) $(memory__h) $(string__h) $(gx_h) 
$(gp_h) \
  $(gsstruct_h) $(gsutil_h) $(stat__h) $(dirent__h)
--------------------------------clip here 
------------------------------
The change here is to copy the "sysv_" make lines into "qnx_" 
make lines and change (1) gp_sysv.* to gp_qnx.* and (2) gp_unifs.* 
to gpqnxfs.*

I copied the gp_sysv.c source to gp_qnx.c and (a) deleted rename() 
because it is supported by the watcom compiler, (b) kept 
gettimeofday(), (c) added the gp_open_scratch_file() which doesn't 
use mktemp().

I copied gp_unifs.c to gp_qnxfs.c and deleted the 
gp_open_scratch_file() because it uses mktemp() which watcom 
does not provide.  Watcom does provide a tmpnam(char *buffer) 
function and more interestingly a FILE *tmpfile(void) function.  
If you ask I can fax you the manual pages.


ANSIHEAD.MAK

Compiler options:
-----------------
I used the Bauer "standard" options for compiling and linking under 
QNX:
--------------------------------clip here 
------------------------------
CFLAGS=-O -w4 -3 -mf $(XCFLAGS)
LDFLAGS=-3 -N 64k -O -g -w3 -mf -fF $(XLDFLAGS)
--------------------------------clip here 
------------------------------
-N 64k gives a big stack size; I don't know if its necessary.
The -mf on CFLAGS and LDFLAGS is very necessary (32-bit flat memory 
model).
The -3 and -O and -g and -w3 and -w4 are just fluff.
The -fF option doesn't make sense to me.

********
******** A guide to the files ********
********

General
-------

There are very few machine dependencies in Ghostscript.  A few of the .c
files are machine-specific.  These have names of the form
	gp_<platform>.c
specifically
	gp_dosfb.c (MS-DOS)
	gp_dosfs.c (MS-DOS and MS Windows)
	gp_itbc.c (MS-DOS, Borland compilers)
	gp_iwatc.c (MS-DOS, Watcom or Microsoft compiler)
	gp_msdos.c (MS-DOS and MS Windows)
	gp_ntfs.c (MS-Windows Win32s and Windows NT)
	gp_os2.c (OS/2)
	gp_os9.c (OS-9)
	gp_unifs.c (Unix or OS-9)
	gp_unix.c (Unix)
	gp_sysv.c (System V Unix)
	gp_vms.c (VMS)
	gp_win32.c (MS-Windows Win32s and Windows NT)
There are also some machine-specific conditionals in files with names
<something>_.h.  If you are going to extend Ghostscript to new
machines or operating systems, you should check the *_.h files for
ifdef's on things other than DEBUG, and you should probably count on
making a new makefile and a new gp_ file.

Library
-------

Files beginning with gs, gx, or gz (both .c and .h), other than gs.c
and gsmain.c, are the Ghostscript library.  Files beginning with gdev
are device drivers or related code, also part of the library.  Other
files beginning with g are library files that don't fall neatly into
either the kernel or the driver category.

Interpreter
-----------

gs.c is the main program for the interactive language interpreter;
gsmain.c is the top level of initialization code.  If you configure
Ghostscript as a server rather than an interactive program, you will use
gsmain.c but not gs.c.

Files named z*.c are Ghostscript operator files.  The names of the files
generally follow the section headings of the operator summary in section
6.2 of the PostScript manual.

Files named i*.c, and *.h other than g*.h, are the rest of the
interpreter.  See the makefile for a little more information on how the
files are divided functionally.

Files named s*.c are a flexible stream package, including the Level 2
PostScript 'filters' supported by Ghostscript.