summaryrefslogtreecommitdiff
path: root/xc/INSTALL.TXT
diff options
context:
space:
mode:
authordaryll <daryll>1999-12-05 00:59:08 +0000
committerdaryll <daryll>1999-12-05 00:59:08 +0000
commit504880db5611bf0f57206abe44835959c2729147 (patch)
treef22ff902680775b5a6fb49364d305b846606716a /xc/INSTALL.TXT
Initial revision
Diffstat (limited to 'xc/INSTALL.TXT')
-rw-r--r--xc/INSTALL.TXT791
1 files changed, 791 insertions, 0 deletions
diff --git a/xc/INSTALL.TXT b/xc/INSTALL.TXT
new file mode 100644
index 000000000..e583fd583
--- /dev/null
+++ b/xc/INSTALL.TXT
@@ -0,0 +1,791 @@
+
+
+
+
+
+
+
+
+
+ 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.
+
+