xc/Attic/INSTALL.TXT - diff

Return to INSTALL.TXT CVS log

Up to [XFree86 CVS] / xc / Attic

Diff for /xc/Attic/INSTALL.TXT between version 1.1.1.4 and 1.1.1.5

version 1.1.1.4, 1996/12/24 09:20:30

version 1.1.1.5, 1998/09/27 07:48:12

Line 7

Building and Installing the X Window System

BBuuiillddiinngg aanndd IInnssttaalllliinngg XX1111RR66..44

Line 16

Stephen Gildea

_K_a_l_e_b _S_. _K_E_I_T_H_L_E_Y

X Consortium

The Open Group X Project Team

March 5, 1996

30 January, 1998

Updated For Release 6.3

Line 37

Line 36

Permission is hereby granted, free of charge, to any person obtaining a

copy of this software and associated documentation files (the

copy of this software and associated documentation files (the Software),

"Software"), to deal in the Software without restriction, including

to use the Software without restriction, including, without limitation,

without limitation the rights to use, copy, modify, merge, publish, dis-

the rights to copy, modify, merge, publish, distribute and sublicense

tribute, sublicense, and/or sell copies of the Software, and to permit

the Software, to make, have made, license and distribute derivative

persons to whom the Software is furnished to do so, subject to the fol-

works thereof, and to permit persons to whom the Software is furnished

lowing conditions:

to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included

The above copyright notice and the following permission notice shall be

in all copies or substantial portions of the Software.

included in all copies of the Software:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL-

IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES OF MERCHANTABIL-

ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT

ITY, FITNESS FOR A PARTICULAR PURPOSE AND NON- INFRINGEMENT. IN NO EVENT

SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL-

SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER USEABILI-

ITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

TIY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS

OUT OF, OR IN CONNNECTION WITH THE SOFTWARE OR THE USE OF OTHER DEALINGS

IN THE SOFTWARE.

Except as contained in this notice, the name of the X Consortium shall

Except as contained in this notice, the name of The Open Group shall not

not be used in advertising or otherwise to promote the sale, use or

be used in advertising or otherwise to promote the use or other dealings

other dealings in this Software without prior written authorization from

in this Software without prior written authorization from The Open

the X Consortium.

Group.

X Window System is a trademark of X Consortium, Inc.

X Window System is a trademark of The Open Group.

1. Easy Build Instructions

_1_. _E_a_s_y _B_u_i_l_d _I_n_s_t_r_u_c_t_i_o_n_s

This quick summary is no substitute for reading the full build instruc-

tions later in this document.

Edit xc/config/cf/site.def for local preferences. If you want to build

Edit xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff for local preferences. If you want to

with gcc uncomment the HasGcc2 line. If you want to install somewhere

install somewhere other than //uussrr//XX1111RR66..44, change PPrroojjeeccttRRoooott. (Do _n_o_t

other than /usr/X11R6.3, change ProjectRoot. (Do not use DESTDIR.)

use DDEESSTTDDIIRR.) If you want to build with _g_c_c uncomment the HHaassGGcccc22 line.

If you have _g_c_c, but not _c_c, please read the full build instructions.

If any fixes have been released by the X Consortium, stop here and fol-

low the instructions at the top of each patch, but don't do any of the

If some time has elapsed since the initial release of R6.4, check to see

make commands suggested in the patches. Then continue here.

if any public patches have been released. The source tar files may have

been updated -- check the patch-level line in the bug-report template.

Check the appropriate vendor-specific .cf file in xc/config/cf/ to make

If the source in the tar files has not been updated then get all the

sure that OSMajorVersion and OSMinorVersion are set correctly for your

patches and apply them, following the instructions at the top of each

system. Override them in site.def if necessary.

patch. Ignore the rebuild steps in the patch application instructions.

See if there is a BootstrapCFlags mentioned in the comments in the

Check the appropriate vendor-specific ..ccff file in xxcc//ccoonnffiigg//ccff// to make

vendor-specific .cf file. If there isn't one, cd to the xc directory

sure that _O_S_M_a_j_o_r_V_e_r_s_i_o_n, _O_S_M_i_n_o_r_V_e_r_s_i_o_n, and _O_S_T_e_e_n_y_V_e_r_s_i_o_n are set

and type:

correctly for your system. On most systems imake will figure these out

automatically; but you may override them in your xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff

if you want.

See if there is a _B_o_o_t_s_t_r_a_p_C_F_l_a_g_s mentioned in the comments in the ven-

dor-specific ..ccff file. (Most systems don't have or need one. The Boot-

strapCFlags in _s_u_n_._c_f is for SunOS 4.0.x, so if you're building on SunOS

4.1.x or SunOS 5/Solaris 2 then BootstrapCFlags doesn't apply.) If there

isn't one, _c_d to the xxcc directory and type (in csh):

% make World >& world.log

If there is a BootstrapCFlags, take its value and type:

If there is an applicable BBoooottssttrraappCCFFllaaggss, take its value and type:

% make World BOOTSTRAPCFLAGS="value" >& world.log

% make World BOOTSTRAPCFLAGS="_v_a_l_u_e" >& world.log

Do not call the output file "make.log" when doing "make World". After a

Line 107

Line 113

% make install.man >& man.log

While the system is building (or if things fail), read the rest of these

WWhhiillee tthhee ssyysstteemm iiss bbuuiillddiinngg ((oorr iiff tthhiinnggss ffaaiill)),, rreeaadd tthhee rreesstt ooff tthheessee

installation instructions.

iinnssttaallllaattiioonn iinnssttrruuccttiioonnss..

2. Building X

This document gives detailed instructions for building Release 6: get-

ting it off the distribution medium, configuring, compiling, installing,

running, and updating.

Release Notes are in xc/RELNOTES.* (various formats) in the distribu-

tion.

More recent information about newly-discovered problems may be found in

the Frequently Asked Questions posting appearing monthly on the

comp.windows.x newsgroup and xpert mailing list. It is also available

via anonymous FTP on ftp.x.org in the file contrib/faqs/FAQ.Z, or on

your local X mirror site.

2.1. Preparing the Site

If you are unpacking tar files, you will need about 130 Mb to hold the

xc/ part. To install requires 30-50 Mb assuming you have shared

libraries (80-100 Mb without). You will need an equivalent amount of

extra space to build, since you also need room for all the object files.

Distributed as tar files, Release 6.3 core is divided into parts as fol-

lows:

xc-1.tar contains everything in xc/ that isn't in the other tar files

xc-2.tar contains xc/fonts, xc/doc/specs, xc/util

xc-3.tar contains xc/doc/hardcopy

If you define BuildFonts to NO, you only need to unpack xc-1.tar to

build. If you build fonts, then you will also need xc-2.tar to build.

2.2. Unpacking the Distribution

The distribution normally comes as multiple tar files, either on tape or

across a network, or as a CD-ROM.

2.2.1. Unpacking a Compressed FTP Distribution

_2_. _B_u_i_l_d_i_n_g _a_n_d _I_n_s_t_a_l_l_i_n_g _R_6_._4

If you have obtained compressed tar files over the network, create a

directory to hold the sources and cd into it:

mkdir sourcedir

Historically the MIT X Consortium and The X Consortium, Inc., sample

cd sourcedir

implementation releases have always been source-code-only releases, and

this release is no different.

Then for each tar file xc-*.tar.Z, execute this:

zcat ftp-dir/xc-N.tar.Z | tar xf -

_2_._1_. _I_n_t_r_o_d_u_c_t_i_o_n

Every release of X has been progressively easier to configure, build,

and install than the preceding releases -- and we believe this release

is the easiest release to build yet. That not withstanding, if things do

go amiss during the build we assume that you have the basic skills nec-

essary, and the willingness, to debug any errors that may occur in the

build process. When you install, if you're going to use _x_d_m or replace

your system's old X, we assume you have a basic understanding of your

system's initialization process. For Remote Execution (RX, embedding) we

assume you that you understand the fundamentals of HTTP, CGI, and HTML.

If these assumptions are not correct then you should consider finding

someone who has proficiency in these areas to do the build and install

for you.

2.2.2. Unpacking a gzipped FTP Distribution

After the release has been out for a while more up to date information

about any newly-discovered problems may be found in the _F_r_e_q_u_e_n_t_l_y _A_s_k_e_d

_Q_u_e_s_t_i_o_n_s posting appearing monthly on the Usenet newsgroup comp.win-

dows.x and xpert mailing list. The FAQ is also available via anonymous

FTP from ftp://ftp.x.org/ in the file ftp://ftp.x.org/con-

trib/faqs/FAQ.Z, or possibly on one of X mirror sites.

If you have obtained gzipped tar files over the network, create a direc-

_2_._2_. _P_r_e_p_a_r_i_n_g _Y_o_u_r _B_u_i_l_d _S_y_s_t_e_m

tory to hold the sources and cd into it:

mkdir sourcedir

cd sourcedir

Then for each tar file xc-*.tar.gz, execute this:

The source is distributed in four gzip compressed UNIX TTape AARRchive

(tar) files. You will need about 200 Mb of disk space in order to unpack

and build the release. Installing requires an additional 30-50 Mb assum-

ing you have shared libraries (80-100 Mb without).

gunzip -c ftp-dir/xc-N.tar.gz | tar xf -

On non-UNIX systems you'll need a utility that can extract gzip com-

pressed tar files to extract the sources. There are several to chose

from, we do not make recommendations about which one you should use.

Release 6.4 sources are distributed among the tar files as follows:

2.2.3. Unpacking a Split Compressed FTP Distribution

tog-1.tar contains everything in xc/ that isn't in the other tar files

tog-2.tar contains xc/fonts

tog-3.tar contains xc/doc/specs, xc/util

tog-4.tar contains xc/doc/hardcopy

If you have obtained compressed and split tar files over the network,

If you define _B_u_i_l_d_F_o_n_t_s to NO in your ssiittee..ddeeff file, then you only need

create a directory to hold the sources:

to unpack tog-1.tar to build. If you build fonts, then you will also

need tog-2.tar to build. If you already have the fonts from prior

releases you can use those instead of downloading them again. We presume

that you know how to copy or move them from your old source tree to the

R6.4 source tree.

mkdir sourcedir

Then for each directory xc-*:

_2_._3_. _U_n_p_a_c_k_i_n_g _t_h_e _D_i_s_t_r_i_b_u_t_i_o_n

cd ftp-dir/xc-N

cat xc-N.?? | uncompress | (cd sourcedir; tar xf -)

Create a directory to hold the sources and _c_d into it:

% mkdir _s_o_u_r_c_e_d_i_r

% cd _s_o_u_r_c_e_d_i_r

2.2.4. Unpacking the Tape Distribution

Then for each tar file ttoogg--**..ttaarr..ggzz, execute this:

% gunzip -c _f_t_p_-_d_i_r/tog-_N.tar.gz | tar xf -

If you have obtained a tape, create a directory to hold the sources and

untar everything into that directory:

mkdir sourcedir

or if you have GNU's tar (FreeBSD, NetBSD, OpenBSD, or Linux too)

cd sourcedir

tar xf tape-device

% tar xzf _f_t_p_-_d_i_r/tog-_N.tar.gz

2.2.5. Using the CD-ROM

_2_._4_. _A_p_p_l_y_i_n_g _P_a_t_c_h_e_s

If you have obtained a CD-ROM, you don't have to do anything to unpack

it. However, you will have to create a symbolic link tree to build X.

See the next section.

To mount the CD-ROM, see the mount(8) manual page on your system or the

If some time has elapsed since the initial release of R6.4, check to see

liner notes that came with the CD-ROM. Some systems, e.g., Solaris 2,

if any public patches have been released. The source tar files may have

can automatically mount the CD-ROM for you.

been updated -- check the patch-level line in the bug-report template.

If the source in the tar files has not been updated then get all the

patches and apply them, following the instructions at the top of each

patch. Ignore the rebuild steps in the patch application instructions.

See the section "Public Patches" later in this document.

2.3. Apply Patches

Then continue here.

If there are fixes released that are more recent than your distribution,

_2_._5_. _C_o_n_f_i_g_u_r_a_t_i_o_n _P_a_r_a_m_e_t_e_r_s _(_I_m_a_k_e _V_a_r_i_a_b_l_e_s_)

apply them now. Follow the instructions at the top of each patch, but

don't do any make commands. See the section "Public Patches" later in

this document. Then continue here.

2.4. Symbolic Link Trees

This release, like all the releases before it, uses _i_m_a_k_e, a utility for

creating system-specific Makefiles from system-independent Imakefiles.

Almost every directory in the release contains an IImmaakkeeffiillee. System-spe-

If you expect to build the distribution on more than one machine using a

cific configuration information is located in xxcc//ccoonnffiigg//ccff//, which is

shared source tree, or you are building from CD-ROM, or you just want to

used by the _i_m_a_k_e program every time a MMaakkeeffiillee is generated in the

keep the source tree pure, you may want to use the program

source tree.

xc/config/util/lndir.c to create a symbolic link tree on each build

machine. The links may use an additional 10 megabytes, but it is

cheaper than having multiple copies of the source tree.

It may be tricky to compile lndir before the distribution is built. If

you have a copy from a previous release, use that. Makefile.ini can be

used for building lndir the first time. You may have to specify

OSFLAGS=-Dsomething to get it to compile. What you would pass as

BOOTSTRAPCFLAGS might work. The command line looks something like this:

make -f Makefile.ini OSFLAGS=-Dflag

To use a symbolic link tree, create a directory for the build, cd to it,

and type this:

lndir sourcedir

where sourcedir is the pathname of the directory where you stored the

sources. All of the build instructions given below should then be done

in the build directory on each machine, rather than in the source direc-

tory.

xc/config/util/mkshadow/ contains mkshadow, an alternative program to

lndir.

2.5. Configuration Parameters

Build information for each source directory is in files called

Imakefile. An Imakefile, along with local configuration information in

xc/config/cf/, is used by the program imake to generate a Makefile.

Most of the configuration work prior to building the release is to set

parameters so that imake will generate correct files. Most of those

parameters (imake variables) so that _i_m_a_k_e will generate correct Make-

parameters are set in xc/config/cf/site.def. You will also need to

files. If you're building on one of the supported systems almost no con-

check the appropriate vendor-specific .cf file in xc/config/cf/ to make

figuration work should be necessary.

sure that OSMajorVersion, OSMinorVersion, and OsTeenyVersion are set

correctly for your system. Override them in site.def if necessary.

You should define your configuration parameters in xxcc//ccoonn--

ffiigg//ccff//ssiittee..ddeeff. We provide an empty ssiittee..ddeeff file and a ssiittee..ssaammppllee

file. The ssiittee..ssaammppllee file is a suggested ssiittee..ddeeff file -- use it at

your own risk.

Any public patches we release will never patch ssiittee..ddeeff, so you can be

assured that applying a public-patch will not corrupt your site.def

file. On rare occasion you may need to make the change in your vendor-

specific ..ccff file; but you should avoid doing that if at all possible

because any patch we might release could conceivably patch your vendor-

specific ..ccff file and your change may be lost or garbled. You can over-

ride most of the things in your vendor-specific ..ccff file in your

ssiittee..ddeeff file. (If you can't, it's a bug -- please file a bug-report.)

On the systems we use here, imake will automatically determine the _O_S_M_a_-

_j_o_r_V_e_r_s_i_o_n, _O_S_M_i_n_o_r_V_e_r_s_i_o_n, and _O_S_T_e_e_n_y_V_e_r_s_i_o_n for your system. If your

system isn't one of the systems we build on here, or you want to build

for a different version of your operating system, then you can override

them in the appropriate entry in your ssiittee..ddeeff file.

The site.def file has two parts, one protected with "#ifdef BeforeVen-

The ssiittee..ddeeff file has two parts, one protected with "#ifdef BeforeVen-

dorCF" and one with "#ifdef AfterVendorCF". The file is actually pro-

cessed twice, once before the .cf file and once after. About the only

cessed twice, once before the ..ccff file and once after. About the only

thing you need to set in the "before" section is HasGcc2; just about

thing you need to set in the "before" section is HHaassGGcccc22; just about

everything else can be set in the "after" section.

The sample site.def also has commented out support to include another

The ssiittee..ssaammppllee also has commented out support to include another file,

file, host.def. This scheme may be useful if you want to set most

hhoosstt..ddeeff. This scheme may be useful if you want to set most parameters

parameters site-wide, but some parameters vary from machine to machine.

site-wide, but some parameters vary from machine to machine. If you use

If you use a symbolic link tree, you can share site.def across all

a symbolic link tree, you can share ssiittee..ddeeff across all machines, and

machines, and give each machine its own copy of host.def.

give each machine its own copy of hhoosstt..ddeeff.

The config parameters are listed in xxcc//ccoonnffiigg//ccff//RREEAADDMMEE, but here are

some of the new or more common parameters that you may wish to set in

your xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff.

The config parameters are listed in xc/config/cf/README, but here are

PPrroojjeeccttRRoooott

some of the more common parameters that you may wish to set in site.def.

ProjectRoot

The destination where X will be installed. This variable needs to

be set before you build, as some programs that read files at run-

time have the installation directory compiled in to them. Assuming

time have the installation directory compiled in to them.

you have set the variable to some value /path, files will be

installed into /path/bin, /path/include/X11, /path/lib, and

/path/man.

HasGccSet to YES to build with gcc version 1.

HasGcc2

Set to YES to build with gcc version 2. Both this option and

HasGcc look for a compiler named gcc, but HasGcc2 will cause the

build to use more features of gcc 2, such as the ability to compile

shared libraries.

BuildXInputExt

Set to YES to build the X Input Extension. This extension requires

device-dependent support in the X server, which exists only in Xhp

in our implementation.

BuildPexExt

HHaassVVaarrDDiirreeccttoorryy

Set to NO to not build the PEX server extension and fonts.

Set to NNOO if your system doesn't have /var or you don't want cer-

tain files to be installed in _V_a_r_D_i_r_e_c_t_o_r_y.

VVaarrDDiirreeccttoorryy

The location of site editable configuration and run-time files.

Many sites prefer to install their X binaries on _r_e_a_d_-_o_n_l_y media --

either a disk slice (partition) that's mounted _r_e_a_d_-_o_n_l_y for added

security, an NFS volume mounted _r_e_a_d_-_o_n_l_y for security and/or

improved VM paging characteristics, or from a _l_i_v_e _f_i_l_e_s_y_s_t_e_m on a

CD-ROM. In order to simplify things like installing _a_p_p_-_d_e_f_a_u_l_t

files for locally built software, and allowing editing of miscella-

neous configuration and policy files, and to allow xdm to create

its master Xauthority file, some directories under _$_P_r_o_j_e_c_t_-

_R_o_o_t//lliibb//XX1111 are actually installed in //vvaarr//XX1111, and _$_P_r_o_j_e_c_t_-

_R_o_o_t//lliibb//XX1111 contains symlinks to the directories in //vvaarr//XX1111.

HHaassGGcccc22

Set to YYEESS to build with _g_c_c version 2.x instead of your system's

default compiler.

BBuuiillddXXIInnppuuttEExxtt

Set to YYEESS to build the X Input Extension. This extension requires

device-dependent support in the X server, which exists only in _X_h_p

and _X_F_8_6___* in the sample implementation.

DefaultUsrBin

DDeeffaauullttUUssrrBBiinn

This is a directory where programs will be found even if PATH is

not set in the environment. It is independent of ProjectRoot and

defaults to /usr/bin. It is used, for example, when connecting

defaults to //uussrr//bbiinn. It is used, for example, when connecting from

from a remote system via rsh. The rstart program installs its

a remote system via _r_s_h. The _r_s_t_a_r_t program installs its server in

server in this directory.

this directory.

InstallServerSetUID

IInnssttaallllSSeerrvveerrSSeettUUIIDD

Some systems require the X server to run as root to access the dev-

Some systems require the X server to run as root to access the

ices it needs. If you are on such a system and will not be using

devices it needs. If you are on such a system and will not be using

xdm, you can set this variable to YES to install the X server

_x_d_m, you may set this variable to YYEESS to install the X server

setuid to root. Note that the X server has not been analyzed by

setuid to root; however the X Project Team strongly recommends that

the X Consortium for security in such an installation; talk to your

you not install your server suid-root, but that you use xdm

system manager before setting this variable.

instead. Talk to your system manager before setting this variable

to YYEESS.

InstallXdmConfig

IInnssttaallllXXddmmCCoonnffiigg

By default set to NO, which suppresses installing xdm config files

over existing ones. Leave it set to NO if your site has customized

the files in /usr/X11R6.3/lib/X11/xdm, as many sites do. If you

the files in _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//xxddmm, as many sites do. If you

don't install the new files, merge any changes present in the new

files.

MotifBC

MMoottiiffBBCC

Causes Xlib and Xt to work around some bugs in older versions of

Motif. Set to YES only if you will be linking with Motif version

Motif. Set to YYEESS only if you will be linking with Motif version

1.1.1, 1.1.2, or 1.1.3.

GetValuesBC

GGeettVVaalluueessBBCC

Setting this variable to YES allows illegal XtGetValues requests

Setting this variable to YYEESS allows illegal XtGetValues requests

with NULL ArgVal to usually succeed, as R5 did. Some applications

erroneously rely on this behavior. Support for this will be

erroneously rely on this behavior. Support for this will be removed

removed in a future release.

in a future release.

The following vendor-specific .cf files are in the release but have not

The following vendor-specific ..ccff files are in the release but have not

been tested recently and hence probably need changes to work:

been tested recently and hence probably need changes to work: aappoolllloo..ccff,

apollo.cf, bsd.cf, convex.cf, DGUX.cf, luna.cf, macII.cf, Mips.cf,

bbssdd..ccff, ccoonnvveexx..ccff, DDGGUUXX..ccff, lluunnaa..ccff, mmaaccIIII..ccff, MMiippss..ccff, mmoottoo..ccff, OOkkii..ccff,

moto.cf, Oki.cf, pegasus.cf, x386.cf. Amoeba.cf is known to require

ppeeggaassuuss..ccff, xx338866..ccff. AAmmooeebbaa..ccff is known to require additional patches.

additional patches.

The file xc/lib/Xdmcp/Wraphelp.c, for XDM-AUTHORIZATION-1, is not

The file xxcc//lliibb//XXddmmccpp//WWrraapphheellpp..cc, for XDM-AUTHORIZATION-1, is not

included in this release.

included in this release. See ftp://ftp.x.org/pub/R6.4/xdm-auth/README.

2.6. System Build Notes

_2_._6_. _S_y_s_t_e_m _B_u_i_l_d _N_o_t_e_s

This section contains hints on building X with specific compilers and

operating systems.

If the build isn't finding things right, make sure you are using a com-

piler for your operating system. For example, a pre-compiled gcc for a

piler for your operating system. For example, a pre-compiled _g_c_c for a

different OS will not have right symbols defined, so imake will not work

different OS (e.g. as a cross-compiler) will not have right symbols

correctly.

defined, so _i_m_a_k_e will not work correctly.

2.6.1. gcc

gcc version 2 is in regular use at the X Consortium on Sparc platforms.

Set the variable HasGcc2. X will not compile on some systems with gcc

version 2.5, 2.5.1, or 2.5.2 because of an incorrect declaration of mem-

move() in a gcc include file.

If you are using a gcc version older than 2.7 on Solaris x86, you need

to specify BOOTSTRAPCFLAGS="-Dsun" in the "make World" command.

2.6.2. Other GNU tools

Use of the GNU assembler, as, or linker, ld, is not supported. GNU make

is not supported.

_2_._6_._1_. _g_c_c

2.6.3. SparcWorks 2.0

X will not compile on some systems with _g_c_c version 2.5, 2.5.1, or 2.5.2

because of an incorrect declaration of memmove() in a gcc fixed include

file.

If you are using a _g_c_c version prior to 2.7 on Solaris x86, you need to

specify BBOOOOTTSSTTRRAAPPCCFFLLAAGGSS==""--DDssuunn"" in the "make World" command.

If you have a non-threaded program and want to debug it with the old

If you're building on a system that has an unbundled compiler, e.g. So-

SparcWorks 2.0 dbx, you will need to use the thread stubs library in

laris 2.x, and you do not have the _c_c compiler, you need to contrive to

xc/util/misc/thr_stubs.c. Compile it as follows:

have _c_c in your path in order to bootstrap imake. One way to do this is

to create a symlink cc that points to _g_c_c.

cc -c thr_stubs.c

% cd /usr/local/bin; ln -s _p_a_t_h_-_t_o_-_g_c_c cc

ar cq libthr_stubs.a thr_stubs.o

ranlib libthr_stubs.a

Install libthr_stubs.a in the same directory with your X libraries

Once _i_m_a_k_e has been built all the Makefiles created with it will explic-

(e.g., /usr/X11R6.3/lib/libthr_stubs.a). Add the following line to

itly use _g_c_c and you can remove the symlink. Another way around this is

site.def:

to edit xxcc//ccoonnffiigg//iimmaakkee//MMaakkeeffiillee..iinnii to specify _g_c_c instead of _c_c.

#define ExtraLibraries -lsocket -lnsl $(CDEBUGFLAGS:-g=-lthr_stubs)

This example uses a make macro substitution; not all make implementa-

_2_._6_._2_. _O_t_h_e_r _G_N_U _t_o_o_l_s

tions support this feature.

Use of the GNU BinUtils assembler, _a_s, and linker, _l_d, is not supported

-- period! If you have them installed on your system you must rename or

remove them for the duration of the R6.4 build. (You can restore them

afterwards.)

2.6.4. CenterLine C under Solaris 2

The system-supplied _m_a_k_e works just fine for building R6.4 and that's

what we suggest you use. If you've replaced your system's _m_a_k_e with GNU

_m_a_k_e then we recommend that you restore the system _m_a_k_e for the duration

of your R6.4 build. After R6.4 is done building you can revert to GNU

make. GNU make on most systems (except Linux, where it is the default

make) is not a supported build configuration. GNU make may work for you,

and if it does, great; but if it doesn't we do not consider it a bug in

R6.4. If, after this admonition, you still use GNU make and your build

fails, reread the above, and retry the build with the system's _m_a_k_e be-

fore you file a bug-report.

If you are using the CenterLine C compiler to compile the distribution

_2_._6_._3_. _I_B_M _A_I_X _4_._x

under Solaris 2, place the following line in your site.def:

#define HasCenterLineC YES

If clcc is not in your default search path, add this line to site.def:

On AIX 4.x, the file lliibb//ffoonntt//TTyyppee11//oobbjjeeccttss..cc must be compiled without

optimization (--OO) or the X server and fontserver will exit when Type 1

fonts are used.

#define CcCmd /path/to/your/clcc

_2_._6_._4_. _S_u_n_O_S _4_._0_._x

If you are using CodeCenter 4.0.4 or earlier, the following files

trigger bugs in the clcc optimizer:

xc/programs/Xserver/cfb16/cfbgetsp.c

SunOS 4.0 and earlier need BOOTSTRAPCFLAGS=-DNOSTDHDRS because it does

xc/programs/Xserver/cfb16/cfbfillsp.c

not have unistd.h and stdlib.h. Do _n_o_t supply a BOOTSTRAPCFLAGS when

xc/programs/Xserver/cfb/cfbgetsp.c

building any SunOS 4.1 or 5.x (Solaris 2) version.

Thus to build the server, you will have to compile these files by hand

_2_._6_._5_. _L_i_n_u_x

with the -g flag:

% cd xc/programs/Xserver/cfb16

% make CDEBUGFLAGS="-g" cfbgetsp.o cfbfillsp.o

% cd ../cfb

% make CDEBUGFLAGS="-g" cfbgetsp.o

This optimizer bug appears to be fixed in CodeCenter 4.0.6.

On Linux systems imake has preliminary support to automatically deter-

mine which Linux distribution you're using. At this time it only auto-

matically detects S.u.S.E. Linux. On other Linux systems you should set

the LinuxDistribution parameter in your xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff -- see the

xxcc//ccoonnffiigg//ccff//lliinnuuxx..ccff file for the list of valid values. On Linux sys-

tems imake will also automatically determine which version of libc and

binutils your system has. You may override these in your xxcc//ccoonn--

ffiigg//ccff//ssiittee..ddeeff file.

Many distributions of Linux have poor or no support for ANSI/POSIX/ISO C

locale support. If your Linux distribution is one of these you should

make certain that the imake variable _L_i_n_u_x_L_o_c_a_l_e_D_e_f_i_n_e_s is set to

--DDXX__LLOOCCAALLEE so that compose processing and other internationalization

features will work correctly. To help decide if you should use -DX_LO-

CALE, look in /usr/share/locale -- if it's empty, you should probably

use the -DX_LOCALE define.

2.6.5. IBM AIX 4.1.4

_2_._6_._6_. _M_i_c_r_o_s_o_f_t _W_i_n_d_o_w_s _N_T

On AIX 4.1.4, the file lib/font/Type1/objects.c must be compiled without

optimization (-O) else the X server will exit when Type 1 fonts are

used.

2.6.6. SunOS 4

SunOS 4.0 and earlier need BOOTSTRAPCFLAGS=-DNOSTDHDRS because they do

not have unistd.h nor stdlib.h. Do not supply a BOOTSTRAPCFLAGS when

building any SunOS 4.1 version.

2.6.7. Microsoft Windows NT

All of the base libraries are supported, including multi-threading in

Xlib and Xt, but some of the more complicated applications, specifically

xterm and xdm, are not supported.

_x_t_e_r_m and _x_d_m, are not supported.

There are also some other rough edges in the implementation, such as

lack of support for non-socket file descriptors as Xt alternate inputs

and not using the registry for configurable parameters like the system

filenames and search paths.

The Xnest server has been made to run on NT. It requires a real X

The _X_n_e_s_t server has been made to run on NT; although it still requires

server for output still.

a real X server for output still. A real X server can not be built from

these sources -- in order to display X applications on a MS-Windows host

you will have to acquire a real X Server.

You have several choices for imake's _R_m_T_r_e_e_C_m_d. Look at the possible

definitions in the xxcc//ccoonnffiigg//ccff//WWiinn3322..ccff file, choose one that's right

for you, and add it to your xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff file.

2.6.8. Omron Luna

_2_._7_. _T_h_e _B_u_i_l_d

The Omron Luna platform is no longer supported. The Luna version of the

make program doesn't define the standard macro MAKE, so you must run it

as "make MAKE=make" at top level, e.g., "make MAKE=make World".

For all the supported UNIX and UNIX-like systems you can simply type (in

csh):

2.7. The Build

% make World >& world.log

You can call the output file something other than "world.log"; but don't

call it "make.log" because files with this name are automatically delet-

ed during the initial "cleaning" stage of the build.

The build can take several hours on older systems, and may take as lit-

tle as an hour on the faster systems that are available today. On UNIX

and UNIX-like systems you may want to run it in the background and keep

a watch on the output. For example:

On NT, type

% make World >& world.log &

% tail -f world.log

nmake World.Win32 > world.log

On other systems, find the BootstrapCFlags line, if any, in the vendor-

If something goes wrong, the easiest thing is to correct the problem and

specific .cf file. If there isn't one, type

start over again, i.e. typing "make World".

% make World >& world.log

otherwise type

_2_._7_._1_. _U_N_I_X _a_n_d _U_N_I_X_-_l_i_k_e _s_y_s_t_e_m_s

% make World BOOTSTRAPCFLAGS="value" >& world.log

Check your vendor-specific ..ccff file; if it doesn't have BootstrapCFlags

that apply to your version of the operating system then type (in csh):

You can call the output file something other than "world.log", but do

% make World >& world.log

not call it "make.log" because files with this name are automatically

deleted during the "cleaning" stage of the build.

Because the build can take several hours to complete, you will probably

want to run it in the background and keep a watch on the output. For

example:

% make World >& world.log &

% tail -f world.log

Otherwise type (in csh):

% make World BOOTSTRAPCFLAGS="value" >& world.log

If something goes wrong, the easiest thing is to just start over (typing

"make World" again) once you have corrected the problem.

None of the _s_u_p_p_o_r_t_e_d operating systems need to use BOOTSTRAPCFLAGS.

2.8. Installing X

_2_._7_._2_. _M_i_c_r_o_s_o_f_t _W_i_n_d_o_w_s _N_T

If everything is built successfully, you can install the software by

typing the following as root:

% make install >& install.log

On NT, make certain your Path, Include, and Lib environment variables

are set accordingly. For example here we use the command line compiler

in VC++ 4.0 Standard Edition, which is installed in C:MSDEVSTD. To setup

the environment type:

> set Path=_o_l_d_-_p_a_t_h;C:\MSDEVSTD\bin;C:\_p_a_t_h_-_t_o_-_R_m_T_r_e_e_C_m_d

> set Include=C:\MSDEVSTD\include

> set Lib=C:\MSDEVSTD\lib

Again, you might want to run this in the background and use tail to

Then to build, at the prompt, type:

watch the progress.

You can install the manual pages by typing the following as root:

C:\> nmake World.Win32 > world.log

% make install.man >& man.log

_2_._8_. _I_n_s_t_a_l_l_i_n_g _X

2.8.1. System Installation Notes

After the build has successfully completed you can install the software

by typing the following as root:

This section contains hints on installing and using X with specific com-

% make install >& install.log

pilers and operating systems.

or on Microsoft Windows NT

C:\> nmake install > install.log

2.8.1.1. The X Server on AIX 4

Again, you might want to run this in the background and use _t_a_i_l to

watch the progress.

For IBM's AIX 4, you need to make sure the LFT device is associated with

You can install the manual pages by typing the following as root:

the correct graphics adapter. It's a one-time setup that does not hap-

pen automatically, even if there's only one graphics adapter in the sys-

tem. To configure the LFT device properly, become root and start SMIT.

Go to the "Devices" category, choose "LFT", then "Displays", then "Move

the LFT to Another Display".

Select "Both" for when the change should take effect, then select the

% make install.man >& man.log

display adapter where you want to run the X server. Confirm the changes

and exit SMIT; from now on, you should be able to run the server just

fine.

To run Xibm from xdm, you must provide the "-force" flag on the server

command line in the Xservers file.

2.9. Shared Libraries

_2_._9_. _S_h_a_r_e_d _L_i_b_r_a_r_i_e_s

The version number of some of the the shared libraries has been changed.

On SunOS 4, which supports minor version numbers for shared libraries,

programs linked with the R6 libraries will use the new libraries with no

programs linked with the R6.4 libraries will use the new libraries with

special action required. On other platforms you have the following

no special action required.

choices:

On most other modern operating systems the version portion of the li-

brary name, i.e. "6.1" portion of "libX11.so.6.1" is a string. Even if

it's only one character long, e.g. "1" (as in libX11.so.1) it's still a

string. This string uniquely identifies and distinguishes one version of

the library from another. Even though all the libraries in this release

are compatible with the libraries from previous releases, and there's

otherwise no reason to change the version string, we do it to identify

which source release the libraries were built from.

An old program that was linked with libXext.so.6.3 won't run if you

delete libXext.so.6.3 and install libXext.so.6.4 in its place. In gener-

al on these systems you have the following choices:

1. Keep the old versions of the libraries around.

2. Relink all applications with the new libraries.

3. Create a link from the old name to the new name.

3. Create a symlink using the old name which points to the new name.

For example, to have programs that were linked against

For example, to have programs that were linked against libX-

libX11.so.6.0 use libX11.so.6.3, make this link:

ext.so.6.3 use libXext.so.6.4, make this symlink:

ln -s libX11.so.6.3 libX11.so.6.0

% cd _$_P_r_o_j_e_c_t_R_o_o_t/lib

% ln -s libXext.so.6.4 libXext.so.6.3

On some distributions of Linux the run-time loader is broken -- requir-

ing that the library's internal SONAME match the _f_i_l_e_n_a_m_e -- and the

symlink solution won't work. We recommend that you get a new run-time

loader which is not broken or recompile your run-time loader to not re-

quire that the SONAME match.

2.10. Setting Up xterm

_2_._1_0_. _S_e_t_t_i_n_g _U_p _x_t_e_r_m

If your /etc/termcap and /usr/lib/terminfo databases do not have correct

entries for xterm, use the sample entries provided in the directory

xc/programs/xterm/. System V users may need to compile and install the

terminfo entry with the tic utility.

Since each xterm will need a separate pseudoterminal, you need a reason-

If your //eettcc//tteerrmmccaapp and //uussrr//lliibb//tteerrmmiinnffoo databases do not have correct

entries for _x_t_e_r_m, use the sample entries provided in the directory

xxcc//pprrooggrraammss//xxtteerrmm//. System V users may need to compile and install the

tteerrmmiinnffoo entry with the _t_i_c utility.

Since each _x_t_e_r_m will need a separate pseudoterminal, you need a reason-

able number of them for normal execution. You probably will want at

least 32 on a small, multiuser system. On most systems, each pty has

least 32 on a small, multiuser system. On most systems, each pty has two

two devices, a master and a slave, which are usually named

devices, a master and a slave, which are usually named

/dev/tty[pqrstu][0-f] and /dev/pty[pqrstu][0-f]. If you don't have at

least the "p" and "q" sets configured (try typing "ls /dev/?ty??"), you

should have your system administrator add them. This is commonly done

by running the MAKEDEV script in the /dev directory with appropriate ar-

by running the _M_A_K_E_D_E_V script in the //ddeevv directory with appropriate ar-

guments.

2.11. Starting Servers at System Boot

_2_._1_1_. _S_t_a_r_t_i_n_g _S_e_r_v_e_r_s _A_u_t_o_m_a_t_i_c_a_l_l_y _a_t _S_y_s_t_e_m _B_o_o_t

The _x_f_s and _x_d_m programs are designed to be run automatically at system

startup. Please read the manual pages for details on setting up configu-

ration files; reasonable sample files are in xxcc//pprrooggrraammss//xxddmm//ccoonnffiigg// and

xxcc//pprrooggrraammss//xxffss//.

The xfs and xdm programs are designed to be run automatically at system

Since _x_f_s can serve fonts over the network, you do not need to run a

startup. Please read the manual pages for details on setting up confi-

font server on every machine with an X display. You should start _x_f_s be-

guration files; reasonable sample files are in xc/programs/xdm/config/

fore _x_d_m, since _x_d_m may start an X server which is a client of (depen-

and xc/programs/xfs/.

dent on) the font server.

2.11.1. On BSD-based systems using /etc/rc

_2_._1_1_._1_. _O_n _B_S_D_-_b_a_s_e_d _s_y_s_t_e_m_s _u_s_i_n_g _/_e_t_c_/_r_c _o_r _/_e_t_c_/_r_c_._l_o_c_a_l

If your system uses an /etc/rc file at boot time, you can usually enable

If your system uses an //eettcc//rrcc or //eettcc//rrcc..llooccaall file at boot time, you

these programs by placing the following at or near the end of the file:

can usually enable these programs by placing the following at or near

the end of the file:

if [ -f /usr/X11R6.3/bin/xfs ]; then

if [ -f _$_P_r_o_j_e_c_t_R_o_o_t/bin/xfs ]; then

/usr/X11R6.3/bin/xfs & echo -n ' xfs'

_$_P_r_o_j_e_c_t_R_o_o_t/bin/xfs & echo -n ' xfs'

if [ -f /usr/X11R6.3/bin/xdm ]; then

if [ -f _$_P_r_o_j_e_c_t_R_o_o_t/bin/xdm ]; then

/usr/X11R6.3/bin/xdm; echo -n ' xdm'

_$_P_r_o_j_e_c_t_R_o_o_t/bin/xdm; echo -n ' xdm'

Since xfs can serve fonts over the network, you do not need to run a

On later versions of FreeBSD the preferred way of doing this is to cre-

font server on every machine with an X display. You should start xfs

ate the directory _$_P_r_o_j_e_c_t_R_o_o_t/etc/rc.d. Add this directory to the _l_o_-

before xdm, since xdm may start an X server which is a client of the

_c_a_l___s_t_a_r_t_u_p variable defined in /etc/rc.conf, and then create short

font server.

scripts in this directory to start xfs and xdm.

The examples here use /usr/X11R6.3/bin, but if you have installed into a

different directory by setting (or unsetting) ProjectRoot then you need

to substitute the correct directory.

If you are unsure about how system boot works, or if your system does

not use /etc/rc, consult your system administrator for help.

not use //eettcc//rrcc, consult your system administrator for help.

_2_._1_1_._2_. _O_n _L_i_n_u_x _s_y_s_t_e_m_s

Most Linux distributions have an /etc/inittab entry specifically for

xdm. Depending on your distribution this may be _r_u_n_-_l_e_v_e_l three, four,

or five. To use xdm, edit //eettcc//iinniittttaabb and find the line which contains

_i_n_i_t_d_e_f_a_u_l_t and change it from 2 to the appropriate run-level

2.11.2. On SystemV-based systems

You Linux distribution may already have a script to start xdm at a par-

ticular run-level. For example on S.u.S.E. Linux 5.0 there is the file

/sbin/init.d/xdm, and the symlink /sbin/init.d/rc3.d/S30xdm which points

to /sbin/init.d/xdm. Change /sbin/init.d/xdm to use _$_P_r_o_j_e_c_t_-

_R_o_o_t_/_b_i_n_/_x_d_m. You can use the xdm script as a model write an xfs script.

Depending on your Linux distribution you may find these files in

/etc/init.d instead of /sbin/init.d.

There are two ways you can get On systems with a /etc/inittab file, you

_2_._1_1_._3_. _O_n _D_i_g_i_t_a_l _U_n_i_x_, _H_P_U_X _1_0_, _a_n_d _S_V_R_4 _s_y_s_t_e_m_s

can edit this file to add the lines

xfs:3:once:/usr/X11R6.3/bin/xfs

xdm:3:once:/usr/X11R6.3/bin/xdm

Most systems run xdm by default at some particular run-level of the sys-

tem. There is a master _i_n_i_t_._d file and a run-level symlink _r_c_?_._d that

points to the master _i_n_i_t_._d file:

Operating System rc?.d symlink init.d file

On some systems, you can edit a file in /etc/init.d to run the X Consor-

Digital Unix 4.0 /sbin/rc3.d/S95xlogin /sbin/init.d/xlogin

tium xdm instead of the vendor's product xdm. On Sony this file is

HPUX 10.20 /sbin/rc3.d/S800xdm /sbin/init.d/xdm

/etc/init.d/consxdm. On IRIX edit /etc/init.d/xdm.

Solaris 2.[0-4]

Solaris 2.5 /etc/rc3.d/S99xdm /etc/init.d/xdm.rc

Solaris 2.6 /etc/rc2.d/S99dtlogin /etc/init.d/dtlogin

IRIX 6.2 /etc/rc2.d/S98xdm /etc/init.d/xdm

Unixware /etc/rc2.d/S69xdm /etc/init.d/xdm

In general you can edit the _i_n_i_t_._d file to use _$_P_r_o_j_e_c_t_R_o_o_t//bbiinn//xxddmm. You

can use the xdm file as a model to write an /etc/rc?.d/S??xfs file to

start xfs. Some systems may already have files to start xfs. Starting in

Solaris 2.5 Sun uses inetd to start xfs -- you should remove the xfs en-

tries from /etc/inetd.conf and /etc/services before adding xfs to the

run-level files.

2.12. Using OPEN LOOK applications

_2_._1_1_._4_. _O_n _S_y_s_t_e_m_V_-_b_a_s_e_d _s_y_s_t_e_m_s

You can use the X11R6 Xsun server with OPEN LOOK applications, but you

must pass the -swapLkeys flag to the server on startup, or the OPEN LOOK

On systems with a //eettcc//iinniittttaabb file, you can edit this file to add the

lines

xfs:3:once:_$_P_r_o_j_e_c_t_R_o_o_t/bin/xfs

xdm:3:once:_$_P_r_o_j_e_c_t_R_o_o_t/bin/xdm

_2_._1_2_. _U_s_i_n_g _O_P_E_N _L_O_O_K _a_p_p_l_i_c_a_t_i_o_n_s

You can use the X11R6.x Xsun server with OPEN LOOK applications; but you

must pass the --sswwaappLLkkeeyyss flag to the server on startup, or the OPEN LOOK

Undo, Copy, Paste, Find, and Cut keys may not work correctly. For exam-

ple, to run Sun's OpenWindows 3.3 desktop environment with an X11R6

server, use the command:

% openwin -server /usr/X11R6.3/bin/Xsun -swapLkeys

% openwin -server _$_P_r_o_j_e_c_t_R_o_o_t_/_b_i_n_/_X_s_u_n _-_s_w_a_p_L_k_e_y_s

The keysyms reported by keys on the numeric keypad have also changed

since X11R5; if you find that OpenWindows applications do not respond to

keypad keys and cursor control keys when using the R6 server, you can

keypad keys and cursor control keys when using an R6 server, you can

remap the keypad to generate R5 style keysyms using the following xmod-

remap the keypad to generate R5 style keysyms using the following

map commands:

_x_m_o_d_m_a_p commands:

keysym Pause = F21

keysym Print = F22

Line 695

Line 721

2.13. Rebuilding after Patches

_2_._1_3_. _R_e_b_u_i_l_d_i_n_g _a_f_t_e_r _P_a_t_c_h_e_s

You shouldn't need this right away, but eventually you are probably go-

ing to make changes to the sources, for example by applying any public

patches that may be released.

Each patch comes with explicit instructions at the top of it saying what

to do. Thus the procedure here is only an overview of the types of com-

mands that might be necessary to rebuild X after changing it.

If you are building from CD-ROM, apply the patches to the symbolic link

Eventually you are going to make changes to the sources, for example by

tree. The links to changed files will be replaced with local files con-

applying any public patches that may be released or to fix any bugs you

taining the new contents.

may have found.

If only source files are changed, you should be able to rebuild just by

If only source files are changed, rebuild by going to the base of your

going to the xc directory in your build tree and typing:

source tree xxcc and typing:

% make >& make.log

If configuration files are changed, the safest thing to do is type:

If there are imake configuration file changes, the best thing to do is

type:

% make Everything >& every.log

"Everything" is similar to "World" in that it rebuilds every Makefile,

"Everything" is similar to "World" in that it rebuilds every MMaakkeeffiillee,

but unlike "World" it does not delete the existing objects, libraries,

and executables, and only rebuilds what is out of date.

2.14. Formatting the Documentation

_2_._1_4_. _F_o_r_m_a_t_t_i_n_g _t_h_e _D_o_c_u_m_e_n_t_a_t_i_o_n

The PostScript files in xc/doc/hardcopy can be generated from the

The PostScript files in xxcc//ddoocc//hhaarrddccooppyy can be generated from the

sources in xc/doc/specs. Most of the documentation is in troff using

sources in xxcc//ddoocc//ssppeeccss. Most of the documentation is in troff using the

the -ms macros. The easiest way to format it is to use the Imakefiles

-ms macros. The easiest way to format it is to use the Imakefiles pro-

provided.

vided.

Set the name of your local troff program by setting the variable

Set the name of your local troff program by setting the variable TTrrooff--

TroffCmd in xc/config/cf/site.def. Then build the Makefiles:

ffCCmmdd in xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff. Then build the Makefiles:

cd xc/doc

make SUBDIRS=specs Makefiles

Finally, go to the directory you are interested in and type "make"

there. This command will generate .PS files. You can also generate

there. This command will generate ..PPSS files. You can also generate text

text files by specifying the document name with a .txt extension as a

files by specifying the document name with a ..ttxxtt extension as a _m_a_k_e

make target, e.g., "make icccm.txt".

target, e.g., "make icccm.txt".

_3_. _P_u_b_l_i_c _P_a_t_c_h_e_s

The Open Group X Project Team may from time to time issue public patches

for this release to fix any serious problems that are discovered. Such

fixes are a subset of fixes available to X Project Team members. Public

patches are available via anonymous FTP from

ftp://ftp.x.org/pub/R6.4/fixes, or from your local X mirror site. Check

the site closest to you first.

You can determine which public patches have already been applied to your

source tree by examining the "VERSION" line of xxcc//bbuugg--rreeppoorrtt. The source

in the tar files you have may already have some patches applied; you on-

ly need to apply later patches. If you try to apply patches out of order

or apply patches that are already in your tree, _p_a_t_c_h will tell you that

you have the wrong version and not apply the patch.

Source for the _p_a_t_c_h program is in xxcc//uuttiill//ppaattcchh//. The _p_a_t_c_h program in-

cluded on some systems may not support all the options this version has.

If you have problems applying patches, or if you're otherwise in doubt,

use this version.

Legend:

Removed from v.1.1.1.4
changed lines
	Added in v.1.1.1.5