649 lines
21 KiB
HTML
649 lines
21 KiB
HTML
<html>
|
|
<head>
|
|
<!-- This file has been generated by unroff 1.0, 03/21/96 19:25:19. -->
|
|
<!-- Do not edit! -->
|
|
<link rev="made" href="mailto:net@informatik.uni-bremen.de">
|
|
<title>X11R6 Release Notes, section 3.</title>
|
|
</head><body>
|
|
<h2><a name="section12">3.</a> <tt> </tt>Building X
|
|
<a name="toc12"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
This section gives detailed instructions for building Release 6:
|
|
getting it off the
|
|
distribution medium, configuring,
|
|
compiling, installing, running, and updating.<tt> </tt>
|
|
<p>
|
|
More recent information about newly-discovered problems may be found
|
|
in the <i>Frequently Asked Questions</i> posting appearing monthly on
|
|
the comp.windows.x newsgroup and xpert mailing list. It is also
|
|
available via anonymous FTP
|
|
on <b>ftp.x.org</b> in the file <b>contrib/faqs/FAQ.Z</b>,
|
|
or on your local X mirror site.<tt> </tt>
|
|
|
|
<h2><a name="section13">3.1.</a> <tt> </tt>Unpacking the Distribution
|
|
<a name="toc13"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The distribution normally comes as multiple tar files, either on
|
|
tape or across a network, or as a CD-ROM.<tt> </tt>
|
|
<p>
|
|
If you are unpacking tar files, you will need about 150 megabytes to
|
|
hold the <b>xc/</b> part.<tt> </tt>
|
|
|
|
<h2><a name="section14">3.1.1.</a> <tt> </tt>Unpacking a Compressed FTP Distribution
|
|
<a name="toc14"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If you have obtained compressed tar files over the network,
|
|
create a directory to hold the sources and <i>cd</i> into it:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
mkdir <i>sourcedir</i>
|
|
cd <i>sourcedir</i>
|
|
</pre>
|
|
</dl>
|
|
Then for each tar file <b>xc-*.tar.Z</b>, execute this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
zcat <i>ftp-dir</i>/xc-<i>N</i>.tar.Z | tar xpf -
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
For each tar file <b>contrib-*.tar.Z</b>, execute this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
zcat <i>ftp-dir</i>/contrib-<i>N</i>.tar.Z | tar xpf -
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section15">3.1.2.</a> <tt> </tt>Unpacking a gzipped FTP Distribution
|
|
<a name="toc15"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If you have obtained gzipped tar files over the network,
|
|
create a directory to hold the sources and <i>cd</i> into it:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
mkdir <i>sourcedir</i>
|
|
cd <i>sourcedir</i>
|
|
</pre>
|
|
</dl>
|
|
Then for each tar file <b>xc-*.tar.gz</b>, execute this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
gunzip -c <i>ftp-dir</i>/xc-<i>N</i>.tar.gz | tar xpf -
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
For each tar file <b>contrib-*.tar.gz</b>, execute this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
gunzip -c <i>ftp-dir</i>/contrib-<i>N</i>.tar.gz | tar xpf -
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section16">3.1.3.</a> <tt> </tt>Unpacking a Split Compressed FTP Distribution
|
|
<a name="toc16"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If you have obtained compressed and split tar files over the network,
|
|
create a directory to hold the sources:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
mkdir <i>sourcedir</i>
|
|
</pre>
|
|
</dl>
|
|
Then for each directory <b>xc-*</b>:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
cd <i>ftp-dir</i>/xc-<i>N</i>
|
|
cat xc-<i>N</i>.?? | uncompress | (cd <i>sourcedir</i>; tar xpf -)
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
For each directory <b>contrib-*</b>, execute this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
cd <i>ftp-dir</i>/contrib-<i>N</i>
|
|
cat contrib-<i>N</i>.?? | uncompress | (cd <i>sourcedir</i>; tar xpf -)
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section17">3.1.4.</a> <tt> </tt>Unpacking the Tape Distribution
|
|
<a name="toc17"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If you have obtained a tape,
|
|
create a directory to hold the sources and untar everything into that
|
|
directory:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
mkdir <i>sourcedir</i>
|
|
cd <i>sourcedir</i>
|
|
tar xpf <i>tape-device</i>
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section18">3.1.5.</a> <tt> </tt>Using the CD-ROM
|
|
<a name="toc18"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
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.<tt> </tt>
|
|
See the next section.<tt> </tt>
|
|
|
|
<h2><a name="section19">3.2.</a> <tt> </tt>Apply Patches
|
|
<a name="toc19"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If there are fixes released, apply them now.<tt> </tt>
|
|
Follow the instructions at the top
|
|
of each patch, but don't do any make commands. Then
|
|
continue here.<tt> </tt>
|
|
|
|
<h2><a name="section20">3.3.</a> <tt> </tt>Symbolic Link Trees
|
|
<a name="toc20"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
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 <b>xc/config/util/lndir.c</b> to create
|
|
a symbolic link tree on each build machine.<tt> </tt>
|
|
The links may use an additional 10 megabytes, but it is cheaper
|
|
than having multiple copies of the source tree.<tt> </tt>
|
|
<p>
|
|
It may be tricky to compile <i>lndir</i> before the distribution is
|
|
built. If you have a copy from Release 5, use that.<tt> </tt>
|
|
<b>Makefile.ini</b> can be used for building <i>lndir</i> the first time.<tt> </tt>
|
|
You may have to specify <b>OSFLAGS=-D</b><i>something</i> to
|
|
get it to compile.<tt> </tt>
|
|
What you would pass as <b>BOOTSTRAPCFLAGS</b> might work.<tt> </tt>
|
|
The command line looks something like this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make -f Makefile.ini OSFLAGS=-D<i>flag</i>
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
To use a symbolic link tree, create a directory for the build, <i>cd</i>
|
|
to it, and type this:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
lndir <i>sourcedir</i>
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
where <i>sourcedir</i> 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.<tt> </tt>
|
|
<p>
|
|
<b>xc/config/util/mkshadow/</b> contains <i>mkshadow</i>, an alternative
|
|
program to <i>lndir</i>.<tt> </tt>
|
|
|
|
<h2><a name="section21">3.4.</a> <tt> </tt>Configuration Parameters
|
|
<a name="toc21"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Build information for each source directory is in files called
|
|
<b>Imakefile</b>. An <b>Imakefile</b>, along with local configuration
|
|
information in <b>xc/config/cf/</b>, is used by the program <i>imake</i>
|
|
to generate a <b>Makefile</b>.<tt> </tt>
|
|
<p>
|
|
Most of the configuration work prior to building the release is to
|
|
set parameters so that <i>imake</i> will generate correct files.<tt> </tt>
|
|
Most of those parameters are set in <b>xc/config/cf/site.def</b>.<tt> </tt>
|
|
You will also need to check the appropriate
|
|
<b>xc/config/cf/</b><i>vendor</i><b>.cf</b> file to make sure that
|
|
OSMajorVersion, OSMinorVersion, and OsTeenyVersion are set correctly
|
|
for your system (change them if necessary).<tt> </tt>
|
|
<p>
|
|
The <b>site.def</b> file has two parts, one protected with
|
|
``#ifdef BeforeVendorCF'' and one with ``#ifdef AfterVendorCF''.<tt> </tt>
|
|
The file is actually processed twice, once before the <b>.cf</b> file
|
|
and once after. About the only thing you need to set in the ``before''
|
|
section is <b>HasGcc2</b>; just about everything else can be set in the
|
|
``after'' section.<tt> </tt>
|
|
<p>
|
|
The sample <b>site.def</b> also has commented out support to include another
|
|
file, <b>host.def</b>. This scheme may be useful if you want to set most
|
|
parameters site-wide, but some parameters vary from machine to machine.<tt> </tt>
|
|
If you use a symbolic link tree, you can share <b>site.def</b> across
|
|
all machines, and give each machine its own copy of <b>host.def</b>.<tt> </tt>
|
|
<p>
|
|
The config parameters are listed in <b>xc/config/cf/README</b>, but
|
|
here are some of the more common parameters that you may wish to set in
|
|
<b>site.def</b>.<tt> </tt>
|
|
<dl>
|
|
<dt><b>ProjectRoot</b><dd>
|
|
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 you
|
|
have set the variable to some value /<i>path</i>, files will be
|
|
installed into /<i>path</i>/bin, /<i>path</i>/include/X11,
|
|
/<i>path</i>/lib, and /<i>path</i>/man.<tt> </tt>
|
|
<dt><b>HasGcc</b><dd>
|
|
Set to <b>YES</b> to build with <i>gcc</i> version 1.<tt> </tt>
|
|
<dt><b>HasGcc2</b><dd>
|
|
Set to <b>YES</b> to build with <i>gcc</i> version 2.<tt> </tt>
|
|
Both this option and <b>HasGcc</b> look for a compiler named <i>gcc</i>,
|
|
but <b>HasGcc2</b> will cause the build to use more features of
|
|
<i>gcc</i> 2, such as the ability to compile shared libraries.<tt> </tt>
|
|
<dt><b>HasCplusplus</b><dd>
|
|
Declares the system has a C++ compiler. C++ is necessary to build
|
|
<i>Fresco</i>. On some systems, you may also have to set additional
|
|
variables to say what C++ compiler you have.<tt> </tt>
|
|
<dt><b>DefaultUsrBin</b><dd>
|
|
This is a directory where programs will be found even if PATH
|
|
is not set in the environment.<tt> </tt>
|
|
It is independent of ProjectRoot and defaults to <b>/usr/bin</b>.<tt> </tt>
|
|
It is used, for example, when connecting from a remote system via <i>rsh</i>.<tt> </tt>
|
|
The <i>rstart</i> program installs its server in this directory.<tt> </tt>
|
|
<dt><b>InstallServerSetUID</b><dd>
|
|
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
|
|
<i>xdm</i>, you can set this variable to <b>YES</b> to install the X
|
|
server setuid to root. Note that the X server has not been analyzed
|
|
by the X Consortium for security in such an installation;
|
|
talk to your system manager before setting this variable.<tt> </tt>
|
|
<dt><b>MotifBC</b><dd>
|
|
Causes Xlib and Xt to work around some bugs in older versions of Motif.<tt> </tt>
|
|
Set to <b>YES</b> only if you will be linking with Motif version 1.1.1,
|
|
1.1.2, or 1.1.3.<tt> </tt>
|
|
<dt><b>GetValuesBC</b><dd>
|
|
Setting this variable to <b>YES</b> 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.<tt> </tt>
|
|
</dl>
|
|
<p>
|
|
The following <i>vendor</i><b>.cf</b> files are in the release but have
|
|
not been tested recently and hence probably need changes to work:
|
|
<b>DGUX.cf</b>, <b>Mips.cf</b>, <b>apollo.cf</b>, <b>bsd.cf</b>,
|
|
<b>convex.cf</b>, <b>moto.cf</b>, <b>pegasus.cf</b>, <b>x386.cf</b>.<tt> </tt>
|
|
<b>Amoeba.cf</b> is known to require additional patches.<tt> </tt>
|
|
<p>
|
|
The file <b>xc/lib/Xdmcp/Wraphelp.c</b>, for XDM-AUTHORIZATION-1, is not
|
|
included in this release. The file is available within the US;
|
|
for details get
|
|
<b>/pub/R6/xdm-auth/README</b> from ftp.x.org via anonymous FTP.<tt> </tt>
|
|
|
|
<h2><a name="section22">3.5.</a> <tt> </tt>System Notes
|
|
<a name="toc22"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
This section contains hints on building X with specific compilers and
|
|
operating systems.<tt> </tt>
|
|
|
|
<h2><a name="section23">3.5.1.</a> <tt> </tt>gcc
|
|
<a name="toc23"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
<i>gcc</i> version 2 is in regular use at the X Consortium.<tt> </tt>
|
|
You should have no
|
|
problems using it to build. Set the variable <b>HasGcc2</b>.<tt> </tt>
|
|
X will not compile on some systems with <i>gcc</i> version 2.5, 2.5.1, or
|
|
2.5.2 because of an incorrect declaration of memmove() in a gcc
|
|
include file.<tt> </tt>
|
|
|
|
<h2><a name="section24">3.5.2.</a> <tt> </tt>SparcWorks 2.0
|
|
<a name="toc24"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
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
|
|
<b>xc/util/misc/thr_stubs.c</b>.<tt> </tt>
|
|
Compile it as follows:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
cc -c thr_stubs.c
|
|
ar cq libthr_stubs.a thr_stubs.o
|
|
ranlib libthr_stubs.a
|
|
</pre>
|
|
</dl>
|
|
Install libthr_stubs.a in the same directory with your X libraries
|
|
(e.g., <b>/usr/X11R6/lib/libthr_stubs.a</b>).<tt> </tt>
|
|
Add the following line to <b>site.def</b>:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define ExtraLibraries -lsocket -lnsl $(CDEBUGFLAGS:-g=-lthr_stubs)
|
|
</pre>
|
|
</dl>
|
|
This example uses a <i>make</i> macro substitution; not all <i>make</i>
|
|
implementations support this feature.<tt> </tt>
|
|
|
|
<h2><a name="section25">3.5.3.</a> <tt> </tt>CenterLine C under Solaris 2.3
|
|
<a name="toc25"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If you are using the CenterLine C compiler to compile the distribution
|
|
under Solaris 2.3,
|
|
place the following line in your <b>site.def</b>:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define HasCenterLineC YES
|
|
</pre>
|
|
</dl>
|
|
If clcc is not in your default search path, add this line to <b>site.def</b>:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define CcCmd /path/to/your/clcc
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
If you are using CodeCenter 4.0.4 or earlier, the following files
|
|
trigger bugs in the <i>clcc</i> optimizer:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
xc/programs/Xserver/cfb16/cfbgetsp.c
|
|
xc/programs/Xserver/cfb16/cfbfillsp.c
|
|
xc/programs/Xserver/cfb/cfbgetsp.c
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Thus to build the server, you will have to compile these files by hand
|
|
with the <b>-g</b> flag:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
% cd xc/programs/Xserver/cfb16
|
|
% make CDEBUGFLAGS="-g" cfbgetsp.o cfbfillsp.o
|
|
% cd ../cfb
|
|
% make CDEBUGFLAGS="-g" cfbgetsp.o
|
|
</pre>
|
|
</dl>
|
|
This optimizer bug appears to be fixed in CodeCenter 4.0.6.<tt> </tt>
|
|
|
|
<h2><a name="section26">3.5.4.</a> <tt> </tt>Microsoft Windows NT
|
|
<a name="toc26"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
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 <i>xterm</i> and <i>xdm</i>,
|
|
are not supported.<tt> </tt>
|
|
<p>
|
|
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.<tt> </tt>
|
|
|
|
<h2><a name="section27">3.6.</a> <tt> </tt>The Build
|
|
<a name="toc27"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
On NT, type
|
|
<dl><dt><dd>
|
|
<pre>
|
|
nmake World.Win32 > world.log
|
|
</pre>
|
|
</dl>
|
|
On other systems, find the BootstrapCFlags line, if any, in the
|
|
<i>vendor</i><b>.cf</b> file. If there isn't one, type
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make World >& world.log
|
|
</pre>
|
|
</dl>
|
|
otherwise type
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make World BOOTSTRAPCFLAGS="value" >& world.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
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.<tt> </tt>
|
|
<p>
|
|
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.<tt> </tt>
|
|
For example:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make World >& world.log &
|
|
tail -f world.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
If something goes wrong, the easiest thing is to just start over
|
|
(typing ``make World'' again) once you have corrected the problem.<tt> </tt>
|
|
It is possible that a failure will corrupt the top-level <b>Makefile</b>.<tt> </tt>
|
|
If that happens, simply delete the file and recreate a workable
|
|
substitute:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
cp Makefile.ini Makefile
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section28">3.7.</a> <tt> </tt>Installing X
|
|
<a name="toc28"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If everything is built successfully, you can install the software
|
|
by typing the following as root:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make install >& install.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Again, you might want to run this in the background and use <i>tail</i>
|
|
to watch the progress.<tt> </tt>
|
|
<p>
|
|
You can install the manual pages by typing the following as root:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make install.man >& man.log
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section29">3.8.</a> <tt> </tt>Shared Libraries
|
|
<a name="toc29"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Except on SunOS 4, the version number of all the shared libraries has
|
|
changed to <b>6.0</b>. 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.<tt> </tt>
|
|
|
|
<h2><a name="section30">3.9.</a> <tt> </tt>Setting Up xterm
|
|
<a name="toc30"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
If your <b>/etc/termcap</b> and <b>/usr/lib/terminfo</b> databases do
|
|
not have correct entries for <i>xterm</i>, use the sample entries
|
|
provided in the directory <b>xc/programs/xterm/</b>. System V users
|
|
may need to compile and install the <b>terminfo</b> entry with the
|
|
<i>tic</i> utility.<tt> </tt>
|
|
<p>
|
|
Since each <i>xterm</i> will need a separate pseudoterminal,
|
|
you need a reasonable number of them for normal execution.<tt> </tt>
|
|
You probably will want at least 32 on a small, multiuser system.<tt> </tt>
|
|
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].<tt> </tt>
|
|
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 <i>MAKEDEV</i> script in
|
|
the <b>/dev</b> directory with appropriate arguments.<tt> </tt>
|
|
|
|
<h2><a name="section31">3.10.</a> <tt> </tt>Starting Servers at System Boot
|
|
<a name="toc31"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The <i>xfs</i> and <i>xdm</i> 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 <b>xc/programs/xdm/config/</b> and <b>xc/programs/xfs/</b>.<tt> </tt>
|
|
<p>
|
|
If your system uses an <b>/etc/rc</b> file at boot time, you can
|
|
usually enable these programs by placing the following at or near the end
|
|
of the file:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
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
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Since <i>xfs</i> 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 <i>xfs</i> before <i>xdm</i>, since
|
|
<i>xdm</i> may start an X server which is a client of the font server.<tt> </tt>
|
|
<p>
|
|
The examples here use <b>/usr/X11R6/bin</b>, but if you have installed into
|
|
a different directory by setting (or unsetting) <b>ProjectRoot</b> then you
|
|
need to substitute the correct directory.<tt> </tt>
|
|
<p>
|
|
If you are unsure about how system boot works, or if your system does
|
|
not use <b>/etc/rc</b>, consult your system administrator for help.<tt> </tt>
|
|
|
|
<h2><a name="section32">3.11.</a> <tt> </tt>Using OPEN LOOK applications
|
|
<a name="toc32"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
You can use the X11R6 Xsun server with OPEN LOOK applications, but you
|
|
must pass the new <b>-swapLkeys</b> flag to the server on startup, or the
|
|
OPEN LOOK Undo, Copy, Paste, Find, and Cut keys may not work correctly.<tt> </tt>
|
|
For example, to run Sun's OpenWindows 3.3 desktop environment with an
|
|
X11R6 server, use the command:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
% openwin -server /usr/X11R6/bin/Xsun -swapLkeys
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
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
|
|
<i>xmodmap</i> commands:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
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
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section33">3.12.</a> <tt> </tt>Rebuilding after Patches
|
|
<a name="toc33"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
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.<tt> </tt>
|
|
<p>
|
|
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.<tt> </tt>
|
|
<p>
|
|
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.<tt> </tt>
|
|
<p>
|
|
If only source files are
|
|
changed, you should be able to rebuild just by going to the <b>xc</b>
|
|
directory in your build tree and typing:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make >& make.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
If configuration files are changed, the safest thing to do is type:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make Everything >& every.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
``Everything'' is similar to ``World'' in that it rebuilds every
|
|
<b>Makefile</b>, but unlike ``World'' it does not delete the
|
|
existing objects, libraries, and executables, and only rebuilds
|
|
what is out of date.<tt> </tt>
|
|
<p>
|
|
Note that in both kinds of rebuilds you do not need to supply the
|
|
<b>BootstrapCFlags</b> value any more; the information is already recorded.<tt> </tt>
|
|
|
|
<h2><a name="section34">3.13.</a> <tt> </tt>Building Contributed Software
|
|
<a name="toc34"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The software in <b>contrib</b> 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 <b>contrib</b>,
|
|
look in its directory for any special build instructions (for example,
|
|
a <b>README</b> file). If there are none, and there is an <b>Imakefile</b>,
|
|
<i>cd</i> to the directory and type:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
xmkmf -a
|
|
make >& make.log
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
This will build a <b>Makefile</b> 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 <b>xc</b>
|
|
software:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
make install >& install.log
|
|
make install.man >& man.log
|
|
</pre>
|
|
</dl>
|
|
|
|
<p><hr>
|
|
Markup created by <em>unroff</em> 1.0, <tt> </tt> <tt> </tt>March 21, 1996, <tt> </tt> <tt> </tt>net@informatik.uni-bremen.de</body>
|
|
</html>
|