For putting out compiler fires.
The autoconfigure system inspects the hardware and software 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. Some programs included in this distribution use cryptographic algorithms to verify server authenticity and credentials. As required by the International Trade in Arms Regulations (ITAR), now called the Defense Trade Regulations (DTR), certain cryptographic products and media, including the Data Encryption Standard (DES), cannot be exported without per-instance license. For this reason, the DES encryption routine has been removed from the the current version, even though it is used only to compute a message digest. Current DTR regulations allow export of the the MD5 message digest routine, which is in fact the preferred algorithm, and this is included in the current version.
The NTP authentication routines conform to the interface used by RSA Laboratories in the rsaref20.zip package, which is downloadable from ftp.rsa.com or via the web at www.rsa.com. Outside the U.S. and Canada, the functionally identical rsaeuro.zip package is available from J.S.A. Kapp and other sources. The recommended way to integrate the DES routines in either package with the NTP build procedures is to copy the desc.c file from the ./source directory in the package to the ./libntp directory in the distribution. Then copy the header files rsaref.h, des.h and md2.h in the ./source directory to the ./include directory. Do not copy the global.h header file; the one in the distribution has been modified. These steps must be completed before the configuration process described below.
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 mkdir A.`config.guess`, 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 ../configure command. The remaining steps are the same whether building in the base directory or in the subdirectory.
Use the make command to compile all source modules, construct the libraries and link the distribution. Expect few or no warnings using cc and a moderate level of warnings using gcc. Note: On some Unix platforms the use of gcc 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 gcc-isms, when gcc is not installed properly, or when operating system updates and patches are applied and gcc is not reinstalled. While the autoconfigure process is quite thorough, the Unix programming cultures of the various workstation makers still remain idiosyncratic.
You are now ready to configure the daemon and start it. You will need to create a NTP configuration file ntp.conf and possibly a cryptographic key file ntp.keys. Directions for doing that are in the Notes on Configuring NTP and Setting up a NTP Subnet. The behavior when the daemon starts for the first time can be counterintuitive. To reduce the level of angst, see the Quick Start page. A tutorial on debugging technique is in NTP Debugging Technique.
If problems peculiar to the particular hardware and software environment (e.g. operating system -specific issues) are suspected, browse the Hints and Kinks page.
Bug reports of a general nature can be sent to David Mills <email@example.com>. Bug reports of a specific nature on features implemented by the programmer corps mentioned in the Copyright page should be sent directly to the implementor listed in that page, with copy to firstname.lastname@example.org.
Please include the version of the source distribution (e.g., ntp- 4.0.70a) in your bug report.
Please include the output of config.guess in your bug report.
It will look something like: pdp11-dec-fuzzos3.4
Additional make commands