This section gives detailed instructions for building Release 6: getting it off the distribution medium, configuring, compiling, installing, running, and updating.
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.
The distribution normally comes as multiple tar files, either on tape or across a network, or as a CD-ROM.
If you are unpacking tar files, you will need about 150 megabytes to hold the xc/ part.
If you have obtained compressed tar files over the network, create a directory to hold the sources and cd into it:
mkdir sourcedir cd sourcedir
zcat ftp-dir/xc-N.tar.Z | tar xpf -
For each tar file contrib-*.tar.Z, execute this:
zcat ftp-dir/contrib-N.tar.Z | tar xpf -
If you have obtained gzipped tar files over the network, create a directory to hold the sources and cd into it:
mkdir sourcedir cd sourcedir
gunzip -c ftp-dir/xc-N.tar.gz | tar xpf -
For each tar file contrib-*.tar.gz, execute this:
gunzip -c ftp-dir/contrib-N.tar.gz | tar xpf -
If you have obtained compressed and split tar files over the network, create a directory to hold the sources:
mkdir sourcedir
cd ftp-dir/xc-N cat xc-N.?? | uncompress | (cd sourcedir; tar xpf -)
For each directory contrib-*, execute this:
cd ftp-dir/contrib-N cat contrib-N.?? | uncompress | (cd sourcedir; tar xpf -)
If you have obtained a tape, create a directory to hold the sources and untar everything into that directory:
mkdir sourcedir cd sourcedir tar xpf tape-device
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.
If there are fixes released, apply them now. Follow the instructions at the top of each patch, but don't do any make commands. Then continue here.
If you expect to build the distribution on more than one machine using a shared source tree, or you are building from CD-ROM, or you just want to keep the source tree pure, you may want to use the program 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 Release 5, 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 directory.
xc/config/util/mkshadow/ contains mkshadow, an alternative program to lndir.
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 are set in xc/config/cf/site.def. You will also need to check the appropriate xc/config/cf/vendor.cf file to make sure that OSMajorVersion, OSMinorVersion, and OsTeenyVersion are set correctly for your system (change them if necessary).
The site.def file has two parts, one protected with ``#ifdef BeforeVendorCF'' and one with ``#ifdef AfterVendorCF''. The file is actually processed twice, once before the .cf file and once after. About the only thing you need to set in the ``before'' section is HasGcc2; just about everything else can be set in the ``after'' section.
The sample site.def also has commented out support to include another file, host.def. 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 site.def across all machines, and give each machine its own copy of host.def.
The config parameters are listed in xc/config/cf/README, but here are some of the more common parameters that you may wish to set in site.def.
The following vendor.cf files are in the release but have not been tested recently and hence probably need changes to work: DGUX.cf, Mips.cf, apollo.cf, bsd.cf, convex.cf, moto.cf, pegasus.cf, x386.cf. Amoeba.cf is known to require additional patches.
The file xc/lib/Xdmcp/Wraphelp.c, for XDM-AUTHORIZATION-1, is not included in this release. The file is available within the US; for details get /pub/R6/xdm-auth/README from ftp.x.org via anonymous FTP.
This section contains hints on building X with specific compilers and operating systems.
gcc version 2 is in regular use at the X Consortium. You should have no problems using it to build. 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 memmove() in a gcc include file.
If you have a non-threaded program and want to debug it with the old SparcWorks 2.0 dbx, you will need to use the thread stubs library in xc/util/misc/thr_stubs.c. Compile it as follows:
cc -c thr_stubs.c ar cq libthr_stubs.a thr_stubs.o ranlib libthr_stubs.a
#define ExtraLibraries -lsocket -lnsl $(CDEBUGFLAGS:-g=-lthr_stubs)
If you are using the CenterLine C compiler to compile the distribution under Solaris 2.3, place the following line in your site.def:
#define HasCenterLineC YES
#define CcCmd /path/to/your/clcc
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 xc/programs/Xserver/cfb16/cfbfillsp.c xc/programs/Xserver/cfb/cfbgetsp.c
Thus to build the server, you will have to compile these files by hand with the -g flag:
% cd xc/programs/Xserver/cfb16 % make CDEBUGFLAGS="-g" cfbgetsp.o cfbfillsp.o % cd ../cfb % make CDEBUGFLAGS="-g" cfbgetsp.o
The set of operating systems that the client-side code will run on has been expanded to include 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.
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.
On NT, type
nmake World.Win32 > world.log
make World >& world.log
make World BOOTSTRAPCFLAGS="value" >& world.log
You can call the output file something other than ``world.log'', but do 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
If something goes wrong, the easiest thing is to just start over (typing ``make World'' again) once you have corrected the problem. It is possible that a failure will corrupt the top-level Makefile. If that happens, simply delete the file and recreate a workable substitute:
cp Makefile.ini Makefile
If everything is built successfully, you can install the software by typing the following as root:
make install >& install.log
Again, you might want to run this in the background and use tail to watch the progress.
You can install the manual pages by typing the following as root:
make install.man >& man.log
Except on SunOS 4, the version number of all the shared libraries has changed to 6.0. If you want programs linked against previous versions of the libraries to use the R6 libraries, create a link from the old name to the new name.
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 reasonable 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 MAKEDEV script in the /dev directory with appropriate arguments.
The xfs and xdm programs are designed to be run automatically at system startup. Please read the manual pages for details on setting up configuration files; reasonable sample files are in xc/programs/xdm/config/ and xc/programs/xfs/.
If your system uses an /etc/rc file at boot time, you can usually enable these programs by placing the following at or near the end of the file:
if [ -f /usr/X11R6/bin/xfs ]; then
/usr/X11R6/bin/xfs &; echo -n ' xfs'
fi
if [ -f /usr/X11R6/bin/xdm ]; then
/usr/X11R6/bin/xdm; echo -n ' xdm'
fi
Since xfs 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 xfs before xdm, since xdm may start an X server which is a client of the font server.
The examples here use /usr/X11R6/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.
You can use the X11R6 Xsun server with OPEN LOOK applications, but you must pass the new -swapLkeys flag to the server on startup, or the OPEN LOOK Undo, Copy, Paste, Find, and Cut keys may not work correctly. For example, to run Sun's OpenWindows 3.3 desktop environment with an X11R6 server, use the command:
% openwin -server /usr/X11R6/bin/Xsun -swapLkeys
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 remap the keypad to generate R5 style keysyms using the following xmodmap 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
You shouldn't need this right away, but eventually you are probably going to make changes to the sources, for example by applying X Consortium public patches.
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 commands that might be necessary to rebuild X after changing it.
If you are building from CD-ROM, apply the patches to the symbolic link tree. The links to changed files will be replaced with a local file containing the new contents.
If only source files are changed, you should be able to rebuild just by going to the xc directory in your build tree and typing:
make >& make.log
If configuration files are changed, the safest thing to do is type:
make Everything >& every.log
``Everything'' is similar to ``World'' in that it rebuilds every Makefile, but unlike ``World'' it does not delete the existing objects, libraries, and executables, and only rebuilds what is out of date.
Note that in both kinds of rebuilds you do not need to supply the BootstrapCFlags value any more; the information is already recorded.
The software in contrib is not set up to have everything built automatically. It is assumed that you will build individual pieces as you find the desire, time, and/or disk space. You need to have the X Consortium part built and installed before building the contributed software. To build a program or library in contrib, look in its directory for any special build instructions (for example, a README file). If there are none, and there is an Imakefile, cd to the directory and type:
xmkmf -a make >& make.log
This will build a Makefile in the directory and all subdirectories, and then build the software. If the build is successful, you should be able to install it using the same commands used for the xc software:
make install >& install.log make install.man >& man.log