⟦eb99e5256⟧

TextFile

.NH
Installation Steps
.PP
This chapter explains in greater detail the steps covered in the overview.
It presumes the source hierarchy has been loaded in some convenient location,
and that the \fI/usr/new\fP directory
and \fI/usr/new/lib\fP directory already exist.
If you
have source or object for other display types in their device dependent
directories, you should edit the X/X/Makefile to build them.
.PP
This distribution was tested under the following versions of different
vendors systems.
.DS
	4.3BSD
	Ultrix 1.2
	Sun 3.0
	Apollo 9.5
	Integrated Solutions 3.07
	IBM 4.2A Release 2.
.DE
You are on your own if you are using versions prior to those listed above.
We recommend upgrading to the later releases.
In particular, the server will not run on IBM 4.2A release 1,
and previous releases of the other systems may or may not work properly.
It is impossible for us to keep straight all the different versions
of different vendor's systems.
.PP
This distribution has not been tested for the Integrated Solutions
machine, as we had none available for testing.
.PP
The Apollo testing showed the installation to be quite rocky,
due to some problems with their C preprocessor,
and there was not time for complete integration of the changes required.
Good luck; you may need it, but it has been seen to work.
.PP
The client code should be easily portable to other 4.2BSD based systems,
the CCI for example.
Some System V based Unix systems also have the Berkeley network
support in them, but you are on your own here.
.NH 2
Prelude
.PP
NOTE:
As X is a network transparent window system, client programs use
network facilities to communicate with the window system.
Make sure your network code works properly BEFORE attempting to use X.
For example, \fItalk(1)\fP should be working properly between normal terminals,
or you should be able to \fIrlogin\fP to either the local or to
another machine if you have a network.
.PP
Also make sure you have made as many pseudo-teletypes as possible
(cd /dev; MAKEDEV pty0; MAKEDEV pty1).
These are used for terminal emulator windows, and it is possible you
may use quite a few of them.
.PP
If you have other machines in your network that run a 4.2BSD derived
system, you can also move the C language source code and recompile it
on those machines.
Performance of the terminal emulator will be improved by use of
4.3BSD's improved pty driver, which is six times faster than the 4.2BSD
version.
The C applications should be able to communicate with the X server on
your display.
.NH 2
Font and Firmware Files
.PP
For each device type supported by X, fonts may differ.
There may also be local installation restrictions which may
prohibit you from using the default location of \fI/usr/new/lib/X\fP
for the fonts or other files needed by X (for example, Vs100 firmware).
In each device dependent X library should be a file \fIvssite.h\fP
which can be tailored to find the fonts and firmware in a different location.
Another reason why you may want to change the font and firmware directory
locations would be to allow use of the display while not having all of
your file systems mounted.
Tailor this file to your taste, and modify the master make file to move
the fonts and firmware to your location.
.PP
The binaries are normally installed into \fI/usr/new\fP.
If you want to change this, edit the master Makefile and change
CONFDIR to the directory you choose.
The entry ``make reconfig'' can be used to automatically edit the Makefiles
in the directories from \fI/usr/new\fP to your new configuration.
.NH 2
Reading the distribution.
.PP
The software comes on a single 1600 BPI magnetic tape in \fItar\fP(1) format.
All files will be extracted into a directory named \fBX\fP.
An example command would be:
.DS
\(bu	tar xf /dev/rmt8
.DE
.PP
If you move the distribution to a different machine than the
one you read the tape on, use care to preserve
the symbolic links, either by moving the distribution as a single file
or by using \fItar\fP across the net.
If you don't, you will end up with more than one copy of certain key
include files, and may get confused later if you make changes.
.NH 2
Building the server
.PP
If you only want to build the client programs on a machine that does
not have a display, you can skip this step.
.PP
If you have a display on your workstation, you can build a server
for your display.
The types of displays supported under the MIT distribution include
the DEC VS100, VS-1, VS-2 and VS-2 RC, most Sun workstation displays,
the Apollo displays, the IBM RT/PC displays under 4.2A only
(this distribution will NOT run under AIX!), and the Integrated
Solutions Optimim V workstations.
Servers for other displays may only be available from the manufacturers.
Examples of this include the Vaxstation II/GPX from Digital, the
HP Bobcats, and Sony displays.
.PP
To build the server for your machine,
type one of the following:
.DS
.ta .5i 2.0i
.TA .5i 2.0i
\(bu	make dec	# for Digital Vs100 and VS1 and VS2
\(bu	make sun	# for Sun workstations
\(bu	make apollo	# for Apollo Computer workstations
\(bu	make is		# for Integrated Solutions workstations
\(bu	make ibm	# for IBM RT/PC under 4.2A
.DE
.PP
This should complete with no errors on the DEC, Sun, and IBM workstations.
The Apollo compiler may generate a number of warnings, and
X/dispatch.c takes a LONG time to compile.
The Apollo preprocessor has problems with several macros new to release 4;
you will have to edit out all occurences of "B16", and "UBPS" should be
changed to 1.
These macros are defined to make it easier to port X to
machines where a short is not 2 bytes.
.NH 2
Building Software
.PP
To build executable versions of all X programs,
execute the command 
.DS
\(bu	make all
.DE
in the main directory.
.PP
Compiling all software takes quite a while. 
Building the X library takes the longest, as there are more than one
hundred fifty modules.
This should complete without error on most machines.
.NH 2
Installing the X Executables
.PP
As super user,
execute the command 
.DS
\(bu	make install
.DE
This should complete without error.
.PP
This  also copies all necessary files for users to program
using X into \fI/usr/include/X\fP.
.PP
You should also install the correct termcap and terminfo (if
applicable)
files out of
\fIxterm/termcap\fP and \fIxterm/terminfo\fP into \fI/etc/termcap\fP
and your terminfo database if they are not already there.
.PP
The \fIxinit\fP program, useful
on machines without the proper init support for login,
expects that the running server to be called "X".
You can either rename the appropriate server for your display,
or use the correct arguments to \fIxinit\fP.
.NH 2
Building a Kernel With the Device Driver
.PP
On some machines, the display driver or other
auxilary file may not come configured into
the system or other device files may not exist.
You must add a line to your configuration file for each display you have.
Make sure the CSR address matches between your configuration file and your
hardware.
The VS100 driver comes with 4.3BSD.
Configure, make, and install the kernel containing the display driver.
When you reboot the machine, make sure that your display auto configures
during boot.
.PP
You should also make a device entry for each display.
For a Vs100, change directory to \fI/dev\fP,
and perform a ``MAKEDEV vs?'', where `?' is the number of the Vs100 as root.
For a QVSS on a MicroVAX,
the command would be 
.DS
\(bu	/etc/mknod /dev/mouse c 35 2	# if /dev/mouse does not exist on a VS-2.
\(bu	/etc/mknod /dev/bell c 12 2	# for bell to ring on a Sun.
\(bu	MAKEDEV displays		# for displays on the RT/PC
.DE
Normally, the protection on the device would be only user read/write,
but for debugging purposes you may want to temporarily change it.
On a DEC VS-2, you should also adb /sys/vaxuba/qv.o and change
the variable "qv_def_scrn" to 2 and rebuild your system.
This will cause the correct screen parameters to be used on the VR-260 monitor.
.NH 2
Testing and Trouble Shooting
.PP
We highly recommend testing before attempting to enable
login on the display.
Error messages will go to your terminal, rather than being logged in 
the file \fI/usr/adm/X?.hosts\fP.
You can use \fIxinit(1)\fP to aid you in testing, but
it is most easily performed from terminal or from across the network.
.PP
To test a Vs100 on line 0, for example,
you would change directory to /usr/new (or wherever you decided to put the
executable programs), and would type ``Xvs100 0 0 &''.
(For a MicroVAX, the command would be ``Xqvss 0 0 &'').
The first argument is which device to use (in this case \fI/dev/vs0\fP
will be used).
There can only be one display on a MicroVAX.
The second argument is ignored.
See the \fIX(8c)\fP and the manual pages
for particular servers manual page for other options.
.PP
If everything succeeds, you should get a grey background and a large
X cursor on the screen.
For reasons we have never understood, it may take three tries to get a
VS100 display to respond.
If not, the most common mistake is the fonts or firmware to be in the
wrong location or a directory or file to not be readable.
.PP
You should now be able to run any of the X programs.
A common beginning mistake would be to forget to set the "DISPLAY"
environment variable.
Most programs also take arguments to specify the host and display number.
So, for convenience while testing, you might execute the
command ``setenv DISPLAY \fIyourhost\fP:0'' where \fIyourhost\fP is the name of your
machine when using the C-shell.
This variable will be set for you automatically
when you log in in the future.
.PP
A common problem that might prevent the \fIxterm(1)\fP
program from working is it
not being set user ID and owned by root.
The installation makefiles should be installing \fIxterm(1)\fP this way.
\fIXterm\fP may also fail if the files described in the previous
section are not consistent, or if you attempt to use an xterm built
before the \fI/etc/init\fP changes were installed.
.PP
If everything is working, you should be ready to enable the line for login.
.NH 2
Automatic Login Support
.PP
Some systems are capable of starting the server and a login \fIxterm\fP
automatically, in particular 4.3BSD and Ultrix 1.2 and later.
If your system does not support the new /etc/ttys format,
you should skip this section.
On other systems, if you have source for 4.3BSD you may want to
install this support.
Mere mortals should probably think long and hard before risking such
installation, but wizards may find it not too difficult.
Affected programs include \fI/etc/init\fP, \fI/etc/getty\fP, \fI/bin/login\fP,
and C library routines \fIttyname\fP(3), \fIisatty\fP(3), \fIttyslot\fP(3) and
all programs that depend on the format of \fI/etc/ttys\fP, \fI/etc/gettytab\fP
and \fI/etc/utmp\fP.
The programs need to be installed as a set, and \fIxterm\fP must be recompiled.
.PP
To avoid a possible race condition, and to allow consistent Unix program
behavior, we dedicate a pseudo teletype for each display's login window.
All other pty's are allocated dynamically when used.
You will use many pty's, so make as many as possible.
Pseudo TTY's come in pairs, the master and the slave.
We rename them to be ``ttyv?'' where `?' is the number of the display.
.PP
So for example,
we might execute the commands:
.DS
\(bu	cd /dev
\(bu	MAKEDEV pty0
\(bu	MAKEDEV pty1
\(bu	mv ttyqf ttyv0		# may already exist on some machines
\(bu	mv ptyqf ptyv0
.DE
and similarly for any other displays.
When logged in, you would appear to be logged in on ``ttyv0'' in this case.
We use the last pseudo teletypes since all other utilities start searching
from lower to higher, and we'd just as soon have them find a pty as soon
as they can.
.NH 2
Configuring Lines in /etc/ttys
.PP
If you started X in the previous step, you will want to abort it now.
For each display you have on a machine, you
must have a line in \fI/etc/ttys\fP to drive the terminal emulator used for
login and the window system server.
NOTE:
The format of the \fI/etc/ttys\fP file has changed radically between 4.2 and
4.3.
You cannot set up a display for login on a 4.2BSD system without installing
new versions of \fI/etc/init\fP,
\fI/etc/getty\fP, and \fI/bin/login\fP from 4.3.
.PP
An example line in \fI/etc/ttys\fP is given in the \fIX(8c)\fP manual page
(though you will have to customize the line for the location and names of
the executable programs).
An example for a Vs100 installed without any reconfiguration on 4.3BSD
might be:
.sp
	ttyv0 "/usr/new/xterm -L =-1+1 :0" xterms on window="/usr/new/Xvs100 0"
.sp
You can customize these commands to taste.
.PP
You can tell \fIinit(8)\fP to re-read the \fI/etc/ttys\fP file by the command
``kill -1 1'' as super user.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦eb99e5256⟧ TextFile

Derivation

TextFile
