150 lines
7.1 KiB
HTML
150 lines
7.1 KiB
HTML
<!-- $NetBSD: build.html,v 1.1 1998/12/30 20:20:33 mcr Exp $ -->
|
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
|
|
<html><head><title>
|
|
Building and Installing the Distribution
|
|
</title></head><body><h3>
|
|
Building and Installing the Distribution
|
|
</h3><hr>
|
|
|
|
<p>Following are instructions to build and install the programs in this
|
|
distribution.
|
|
|
|
<p>Note that the automatic build process inspects the machine
|
|
environment and tests for the presence of system header files and the
|
|
contents of these files to determine if certain features are available.
|
|
When one or more of these features are present, the code is compiled to
|
|
use them; if not, no special code is compiled. However, even if the code
|
|
is compiled to use these features, the code does a special test at run
|
|
time to see if one or more are actually present and avoids using them if
|
|
not present. In such cases a warning message is sent to the system log,
|
|
but the daemon should still work properly.
|
|
|
|
<p><h4>Building and Installing under Unix</h4>
|
|
|
|
<p>Make sure that you have all necessary tools for building executables.
|
|
These tools include <code>cc/gcc, make, awk, sed, tr, sh, grep,
|
|
egrep</code> and a few others. Not all of these tools exist in the
|
|
standard distribution of modern Unix versions (compilers are likely to
|
|
be an add-on product - consider using the <code>gnu</code> tools and
|
|
<code>gcc</code> compiler in this case). For a successful build, all of
|
|
these tools should be accessible via the current path.
|
|
|
|
<h5>Configuration</h5>
|
|
|
|
<p>Use the <code>configure</code> command to perform an automatic
|
|
configuration procedure. This procedure normally includes the debugging
|
|
code, which can be useful in diagnosing problems found in initial test,
|
|
and all reference clock drivers known to work with each machine and
|
|
operating system. Unless memory space is at a premium, this is a
|
|
sensible strategy and saves lots of messy fiddling. If you need to
|
|
delete either the debugging code or one or more or all reference clock
|
|
drivers to save space, see the <a href="config.html">Configuration
|
|
Options</a> page.
|
|
|
|
<p>If your site supports multiple architectures and uses NFS to share
|
|
files, you can use a single source tree to compile executables for all
|
|
architectures. While running on a target architecture machine and with
|
|
the distribution base directory active, create a subdirectory using a
|
|
command like <code>mkdir `config.guess`</code>, which will create an
|
|
architecture-specific directory with name peculiar to the architecture
|
|
and operating system. Then change to this directory and configure with
|
|
the <code>../configure</code> command. The remaining steps are the same
|
|
whether building in the base directory or in the subdirectory.
|
|
|
|
<h5>Compilation</h5>
|
|
|
|
<p>Use the <code>make</code> command to compile all source modules,
|
|
construct the libraries and link the distribution. Expect few or no
|
|
warnings using <code>cc</code> and a moderate level of warnings using
|
|
<code>gcc</code>. Note: On some Unix platforms the use of
|
|
<code>gcc</code> can result in quite a few complaints about system
|
|
header files and type inconsistencies, especially about pointer
|
|
variables. This is usually the case when the system header files are not
|
|
up to ANSI standards or <code>gcc</code>-isms. While the autoconfigure
|
|
process is quite thorough, the Unix programming cultures of the various
|
|
workstation makers still remain idiosyncratic.
|
|
|
|
<h5>Installation</h5>
|
|
<p>As root, use the <code>make install</code> command to install the
|
|
binaries in the destination directory. You must of course have write
|
|
permission on the install destination directory. This includes the
|
|
programs <a href="xntpd.html"><code>xntpd</code></a> (the daemon), <a
|
|
href="xntpdc.html"><code>xntpdc</code></a> (an <code>xntpd</code>-
|
|
dependent query program), <a href="ntpq.html"><code>ntpq</code></a> (a
|
|
standard query program), <a href="ntpdate.html"><code>ntpdate</code></a>
|
|
(an <code>rdate</code> replacement for boot time date setting and sloppy
|
|
time keeping) and <a href="ntptrace.html"><code>ntptrace</code></a> (a
|
|
utility useful to find the primary (stratum-1) servers). In some
|
|
systems, the <a href="tickadj.html"><code>tickadj</code></a> (a utility
|
|
useful to adjust kernel variables) is installed. If the precision time
|
|
kernel modifications are present, the <a
|
|
href="ntptime.html"><code>ntptime</code></a> (a utility useful to debug
|
|
kernel time functions) is installed.
|
|
|
|
<p>You are now ready to configure the daemon and start it. You will need
|
|
to create a NTP configuration file <code>ntp.conf</code> and possibly a
|
|
cryptographic key file <code>ntp.keys</code>. Directions for doing that
|
|
are in the <a href="notes.html">Notes on Configuring NTP and Setting up
|
|
a NTP Subnet</a>. A tutorial on debugging technique is in <a
|
|
href="debug.html">NTP Debugging Technique</a>. If problems peculiar to
|
|
the particular hardware and software environment are suspected, browse
|
|
the <a href="http:hints.html">Hints and Kinks</a> page.
|
|
|
|
<p>Bug reports of a general nature can be sent to David Mills
|
|
(mills@udel.edu). Bug reports of a specific nature on features
|
|
implemented by the programmer corps mentioned in the <a
|
|
href="copyright.html">Copyright</a> page should be sent directly to the
|
|
implementor listed in that page, with copy to mills@udel.edu.
|
|
|
|
<p><strong>Please include the version of the source distribution (e.g.,
|
|
xntp3-5.87) in your bug report.</strong>
|
|
|
|
<p><strong>Please include the output of <code>config.guess</code> in
|
|
your bug report.</strong>
|
|
|
|
<p><strong>It will look something like:
|
|
<code>pdp11-dec-fuzzos3.4</code></strong>
|
|
|
|
<p>Additional <code>make</code> commands
|
|
|
|
<dl>
|
|
|
|
<dt><code>make clean</code>
|
|
<dd>Cleans out object files, programs and temporary files.
|
|
|
|
<p><dt><code>make distclean</code>
|
|
<dd>Does the work of <code>clean</code>, but cleans out all directories
|
|
in preparation for a new distribution release.
|
|
|
|
<p><dt><code>make dist</code>
|
|
<dd>Does the work of <code>make distclean</code>, but constructs
|
|
compressed tar files for distribution. You must have GNU automake to
|
|
perform this function.
|
|
|
|
</dl>
|
|
|
|
<p><h4>Building and Installing under Windows NT</h4>
|
|
|
|
<p>Under Windows NT, you will need <code>Visual C++ 4.0</code> or above,
|
|
<code>InstallShield</code> SDK (comes with <code>VC++</code>),
|
|
<code>Perl5</code> and some version of the archiving program
|
|
<code>ZIP</code>.
|
|
|
|
<p>See the <code>./scripts/wininstall/readme.nt</code> file for
|
|
directions to compile the sources, build the libraries and link the
|
|
executables. Initiate the build by running either <code>bldrel.bat</code>
|
|
or <code>blddbg.bat</code> to compile all of the source and create an
|
|
<code>InstallShield</code> based graphical installation package.
|
|
|
|
<p>To install the executables, make sure that you are logged in as a
|
|
system account, or one with administrator privileges such as the
|
|
"administrator" account. As part of the build an
|
|
<code>InstallShield</code> based graphical installer was created. Run
|
|
<code>\xntp\scripts\wininstall\intel\disk1\setup.exe</code> to begin the
|
|
installation. This installer will prompt for basic defaults, copy the
|
|
binaries, install the service, and start it up. The other option is
|
|
to run <code>\xntp\scripts\wininstall\distrib\install.bat</code> which
|
|
will do the basic installation from the command line.
|
|
|
|
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
|