path: root/xc/INSTALL.TXT

                    BBuuiillddiinngg aanndd IInnssttaalllliinngg XX1111RR66..44








                           _K_a_l_e_b _S_. _K_E_I_T_H_L_E_Y

                     The Open Group X Project Team






                            30 January, 1998










Copyright (C) 1998 The Open Group

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the Software),
to use the Software without restriction, including, without limitation,
the rights to copy, modify, merge, publish, distribute and sublicense
the Software, to make, have made, license and distribute derivative
works thereof, and to permit persons to whom the Software is furnished
to do so, subject to the following conditions:

The above copyright notice and the following permission notice shall be
included in all copies of the Software:

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES OF MERCHANTABIL-
ITY, FITNESS FOR A PARTICULAR PURPOSE AND NON- INFRINGEMENT. IN NO EVENT
SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER USEABILI-
TIY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
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 Open Group shall not
be used in advertising or otherwise to promote the use or other dealings
in this Software without prior written authorization from The Open
Group.

X Window System is a trademark of The Open Group.


_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 xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff for local preferences.  If you want to
install somewhere other than //uussrr//XX1111RR66..44, change PPrroojjeeccttRRoooott. (Do _n_o_t
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 some time has elapsed since the initial release of R6.4, check to see
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.
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.

Check the appropriate vendor-specific ..ccff file in xxcc//ccoonnffiigg//ccff// to make
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
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 an applicable BBoooottssttrraappCCFFllaaggss, take its value and type:

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


Do not call the output file "make.log" when doing "make World".  After a
successful build, you can install with:

        % make install >& install.log


You can install manual pages with:

        % make install.man >& man.log


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



_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


Historically the MIT X Consortium and The X Consortium, Inc., sample
implementation releases have always been source-code-only releases, and
this release is no different.


_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.

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.


_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


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).

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:


        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 define _B_u_i_l_d_F_o_n_t_s to NO in your ssiittee..ddeeff file, then you only need
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.


_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


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

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

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


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

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



_2_._4_.  _A_p_p_l_y_i_n_g _P_a_t_c_h_e_s


If some time has elapsed since the initial release of R6.4, check to see
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.
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.

Then continue here.


_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_)


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-
cific configuration information is located in xxcc//ccoonnffiigg//ccff//, which is
used by the _i_m_a_k_e program every time a MMaakkeeffiillee is generated in the
source tree.

Most of the configuration work prior to building the release is to set
parameters (imake variables) so that _i_m_a_k_e will generate correct Make-
files. If you're building on one of the supported systems almost no con-
figuration work should be 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 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 ..ccff file and once after. About the only
thing you need to set in the "before" section is HHaassGGcccc22; just about
everything else can be set in the "after" section.

The ssiittee..ssaammppllee also has commented out support to include another file,
hhoosstt..ddeeff. This scheme may be useful if you want to set most parameters
site-wide, but some parameters vary from machine to machine.  If you use
a symbolic link tree, you can share ssiittee..ddeeff across all machines, and
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.

PPrroojjeeccttRRoooott
     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.

HHaassVVaarrDDiirreeccttoorryy
     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.

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 //uussrr//bbiinn. It is used, for example, when connecting from
     a remote system via _r_s_h. The _r_s_t_a_r_t program installs its server in
     this directory.

IInnssttaallllSSeerrvveerrSSeettUUIIDD
     Some systems require the X server to run as root to access the
     devices it needs. If you are on such a system and will not be using
     _x_d_m, you may set this variable to YYEESS to install the X server
     setuid to root; however the X Project Team strongly recommends that
     you not install your server suid-root, but that you use xdm
     instead. Talk to your system manager before setting this variable
     to YYEESS.

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 _$_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.

MMoottiiffBBCC
     Causes Xlib and Xt to work around some bugs in older versions of
     Motif.  Set to YYEESS only if you will be linking with Motif version
     1.1.1, 1.1.2, or 1.1.3.

GGeettVVaalluueessBBCC
     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 removed
     in a future release.

The following vendor-specific ..ccff files are in the release but have not
been tested recently and hence probably need changes to work: aappoolllloo..ccff,
bbssdd..ccff, ccoonnvveexx..ccff, DDGGUUXX..ccff, lluunnaa..ccff, mmaaccIIII..ccff, MMiippss..ccff, mmoottoo..ccff, OOkkii..ccff,
ppeeggaassuuss..ccff, xx338866..ccff.  AAmmooeebbaa..ccff is known to require additional patches.

The file xxcc//lliibb//XXddmmccpp//WWrraapphheellpp..cc, for XDM-AUTHORIZATION-1, is not
included in this release. See ftp://ftp.x.org/pub/R6.4/xdm-auth/README.


_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 _g_c_c for a
different OS (e.g. as a cross-compiler) will not have right symbols
defined, so _i_m_a_k_e will not work correctly.


_2_._6_._1_.  _g_c_c

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're building on a system that has an unbundled compiler, e.g.  So-
laris 2.x, and you do not have the _c_c compiler, you need to contrive to
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.

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

Once _i_m_a_k_e has been built all the Makefiles created with it will explic-
itly use _g_c_c and you can remove the symlink. Another way around this is
to edit xxcc//ccoonnffiigg//iimmaakkee//MMaakkeeffiillee..iinnii to specify _g_c_c instead of _c_c.


_2_._6_._2_.  _O_t_h_e_r _G_N_U _t_o_o_l_s

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.)

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.


_2_._6_._3_.  _I_B_M _A_I_X _4_._x


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.


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


SunOS 4.0 and earlier need BOOTSTRAPCFLAGS=-DNOSTDHDRS because it does
not have unistd.h and stdlib.h. Do _n_o_t supply a BOOTSTRAPCFLAGS when
building any SunOS 4.1 or 5.x (Solaris 2) version.


_2_._6_._5_.  _L_i_n_u_x


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_._6_.  _M_i_c_r_o_s_o_f_t _W_i_n_d_o_w_s _N_T


All of the base libraries are supported, including multi-threading in
Xlib and Xt, but some of the more complicated applications, specifically
_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 _X_n_e_s_t server has been made to run on NT; although it still requires
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_._7_.  _T_h_e _B_u_i_l_d


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

        % 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:

        % make World >& world.log &
        % tail -f world.log


If something goes wrong, the easiest thing is to correct the problem and
start over again, i.e. typing "make World".


_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


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):

        % make World >& world.log


Otherwise type (in csh):

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


None of the _s_u_p_p_o_r_t_e_d operating systems need to use BOOTSTRAPCFLAGS.


_2_._7_._2_.  _M_i_c_r_o_s_o_f_t _W_i_n_d_o_w_s _N_T


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

Then to build, at the prompt, type:

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



_2_._8_.  _I_n_s_t_a_l_l_i_n_g _X


After the build has successfully completed you can install the software
by typing the following as root:

        % make install >& install.log

or on Microsoft Windows NT

        C:\> nmake install > install.log


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

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

        % make install.man >& man.log



_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.4 libraries will use the new libraries with
no special action required.

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 symlink using the old name which points to the new name.

     For example, to have programs that were linked against libX-
     ext.so.6.3 use libXext.so.6.4, make this symlink:

             % 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_._1_0_.  _S_e_t_t_i_n_g _U_p _x_t_e_r_m


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 two
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 _M_A_K_E_D_E_V script in the //ddeevv directory with appropriate ar-
guments.


_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//.

Since _x_f_s can serve fonts over the network, you do not need to run a
font server on every machine with an X display. You should start _x_f_s be-
fore _x_d_m, since _x_d_m may start an X server which is a client of (depen-
dent on) the font server.


_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 //eettcc//rrcc or //eettcc//rrcc..llooccaall file at boot time, you
can usually enable these programs by placing the following at or near
the end of the file:

        if [ -f _$_P_r_o_j_e_c_t_R_o_o_t/bin/xfs ]; then
                _$_P_r_o_j_e_c_t_R_o_o_t/bin/xfs & echo -n ' xfs'
        fi

        if [ -f _$_P_r_o_j_e_c_t_R_o_o_t/bin/xdm ]; then
                _$_P_r_o_j_e_c_t_R_o_o_t/bin/xdm; echo -n ' xdm'
        fi


On later versions of FreeBSD the preferred way of doing this is to cre-
ate the directory _$_P_r_o_j_e_c_t_R_o_o_t/etc/rc.d. Add this directory to the _l_o_-
_c_a_l___s_t_a_r_t_u_p variable defined in /etc/rc.conf, and then create short
scripts in this directory to start xfs and xdm.

If you are unsure about how system boot works, or if your system does
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

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.


_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


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

Digital Unix 4.0    /sbin/rc3.d/S95xlogin    /sbin/init.d/xlogin
HPUX 10.20          /sbin/rc3.d/S800xdm      /sbin/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_._1_1_._4_.  _O_n _S_y_s_t_e_m_V_-_b_a_s_e_d _s_y_s_t_e_m_s


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 _$_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 an R6 server, you can
remap the keypad to generate R5 style keysyms using the following
_x_m_o_d_m_a_p commands:

        keysym Pause = F21
        keysym Print = F22
        keysym Break = F23
        keysym KP_Equal = F24
        keysym KP_Divide = F25
        keysym KP_Multiply = F26
        keysym KP_Home = F27
        keysym KP_Up = Up
        keysym KP_Prior = F29
        keysym KP_Left = Left
        keycode 100 = F31
        keysym KP_Right = Right
        keysym KP_End = F33
        keysym KP_Down = Down
        keysym KP_Next = F35
        keysym KP_Insert = Insert
        keysym KP_Delete = Delete



_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


Eventually you are going to make changes to the sources, for example by
applying any public patches that may be released or to fix any bugs you
may have found.

If only source files are changed, rebuild by going to the base of your
source tree xxcc and typing:

        % make >& make.log


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 MMaakkeeffiillee,
but unlike "World" it does not delete the existing objects, libraries,
and executables, and only rebuilds what is out of date.


_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 xxcc//ddoocc//hhaarrddccooppyy can be generated from the
sources in xxcc//ddoocc//ssppeeccss. Most of the documentation is in troff using the
-ms macros. The easiest way to format it is to use the Imakefiles pro-
vided.

Set the name of your local troff program by setting the variable TTrrooff--
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 ..PPSS files. You can also generate text
files by specifying the document name with a ..ttxxtt extension as a _m_a_k_e
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.