1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
For special hints on setup/compilation/installation and other general
topics you may persue the files in the hints directory.
This file contains the usual instructions to compile and install the programs in
this distribution. To make these programs:
(0) Make sure that you have all necessary tools for building executables.
These tools include cc/gcc, make, awk, sed, tr, sh, grep, egrep and
a few others. Not all of these tools exist in the standard distribution
of todays Unix versions (Compilers are likely to be an extra product).
For a successful build all of these tools should be accessible via the
current path.
(1) By default, if there is no Config.local, the system will generate one
to support a local ref clock (i.e. run off the system clock).
Greenhorns can skip on to (2).
HACKers can create a Config.local and choose the compilation options,
install destination directory and clock drivers.
A template for Config.local can be found in Config.local.dist.
There are two Configurations that can be auto-generated:
make Config.local.local # network configuration plus local
# reference clock (the default)
make Config.local.NO.clock # network only configuration
To set up for a radio clock, type "make refconf" and answer the questions
about PLL, PPS and radio clock type.
If this is the first use of the ref clock, don't forget to make suitable
files in /dev/
For custom tailored configuration copying Config.local.dist to Config.local
and editing Config.local to suit the local needs is neccessary (at most
3 lines to change), or use one of the make's above and then tweak it.
(2) Type "make" to compile everything of general interest. 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 problems within xntp
code. This is usually the case when the OS header files are not up
up to ANSI standards or GCCISMs. (There may, however, be still some
inconsistencies in the code)
Other known problems stem from bugs/features/... in utility programs
of some vendors.
See section "build problems" for known problems and possible work-
arounds.
Each time you change the configuration a script that pokes your hard- and
software will be run to build the actual configuration files.
If the script fails, it will give you a list of machines it knows about.
You can override the automatic choice by cd to the ../machines directory
and typing "make makeconfig OS=<machine>", where <machine> is one of the
file names in the ../machine directory.
The shell script will attempt to find the gcc compiler and, if
found, will use it instead of the cc compiler. You can override
this automatic choice by cd to the ../machines directory and typing
"make makeconfig COMP=<compiler>", where <compiler> is one of the file
names in the ../compilers directory. This can be combined with
the OS argument above.
The configuration step can be separatly invoked by "make makeconfig".
Note that any reconfiguration will result in cleaning the old
program and object files.
(3) Assuming you have write permission on the install destination directory,
type "make install" to install the binaries in the destination directory.
At the time of writing this includes
the programs xntpd (the daemon), xntpdc (an xntpd-dependent query
program), ntpq (a standard query program), ntpdate (an rdate
replacement for boot time date setting and sloppy time keeping)
and xntpres (a program which provides name resolver support for
some xntpd configurations).
(4) You are now ready to configure the daemon and start it. At this
point it might be useful to format and print the file doc/notes.me
and read a little bit. The sections on configuration and on the
tickadj program will be immediately useful.
Additional "make" target you might find useful are:
clean cleans out object files, programs and temporary files
dist makes a new distribution file (also cleans current binaries)
All usual scratch and backup files (*.rej, *.orig, *.o, *~
core, lint*.errs, executables, tags, Makefile.bak, make.log)
will be removed. The distribution is created in a tar file
(file name: <prefix><version>.tar.<compression suffix> - with
the prefix usually being ../xntp- and a compression suffix
of .Z (compress))
Note: the file Config.local will never be included in the
distribution tar file. For configuration hints to propagate
in in distribution changes must be made to Config.local.dist.
depend possible maker of hazardous waste
refconf a target to interactively configure reference clock support.
This should work for you, but has not yet been tested on
the more exotic Unix ports (mostly the supercomputer ones).
Bug reports of a general nature can be sent to David Mills (mills@udel.edu).
Reports concerning specific hardware or software systems mentioned in the
COPYRIGHT file should be sent to the author, with copy to David Mills for
archive.
The distribution has been compiled and run on at least the following
machines, operating systems and compilers. In all known cases, if
the gcc compiler eats it with some success, the cc compiler also enjoys
the meal. The converse is not always true.
VAX-11/785 4.3 tahoe cc no REFCLOCK (dm 93/11/20)
Sun3 SunOS 4.1.1 gcc no REFCLOCK (pb 93/10/25)
Sun4 SunOS 4.1.1 gcc all REFCLOCK drivers (dm 93/10/25)
Sun4 SunOS 4.1.3 gcc all REFLCOCK drivers
Sun4 SunOS 5.1 gcc no REFCLOCK (pb 93/10/25)
Sun4 SunOS 5.2 gcc no REFCLOCK (dm 93/11/20)
Sun4 SunOS 5.2 gcc PARSE REFCLOCK (kd 93/11/10)
Sun4 SunOS 5.3 gcc local (pb 93/11/10)
HP700 HPUX 9.0 cc no REFCLOCK
hp7xx HPUX 9.01 cc local + PARSE (kd 93/10/26)
HP3xx HPUX 9.01 cc no REFCLOCK (pb 93/10/25)
HP3xx HPUX 8.0 cc no REFCLOCK (pb 93/10/25)
MIPS Ultrix 4.3a gcc WWVB clock (dm 93/11/20)
MIPS Ultrix 3a gcc green (pb 93/10/26)
ALPHA OSF 1.2a gcc no REFCLOCK (dm 93/11/20)
ALPHA OSF 1.3 gcc no REFCLOCK (pb 93/10/25)
ALPHA OSF1 1.3 gcc green (pb 93/10/26)
Convex Convex OS 10.1 ? ?
SGI IRIX 4.0.5F gcc no REFCLOCK (pb 93/11/10)
AIX 3.2 ? ?
A/UX 2.0.1, 3.0.x ? ?
RS6000 AIX 3.2 gcc no REFCLOCK
MX500 Sinix-m V5.40 cc PARSE REFCLOCK
S2000 Sequent PTX 1.4 cc LOCAL_CLOCK (kd 93/11/10)
S2000 Sequent PTX 1.4 gcc LOCAL_CLOCK (kd 93/11/10)
PC FreeBSD gcc LOCAL_CLOCK see "build problems"
PC NetBSD? gcc LOCAL_CLOCK possibly see "build problems"
PC BSDI? gcc LOCAL_CLOCK possibly see "build problems"
PC Linux (pl14) gcc LOCAL_CLOCK (dw 93/10/30)
pb: Piete Brooks
kd: Frank Kardel
dw: Torsten Duwe (duwe@informatik.uni-erlangen.de)
dm: David Mills (mills@udel.edu)
Build Problems (and workaround):
During testing/porting we have found some
of "make" and "sh" and "awk" features in different implementations.
If you have problems other tha the one listed below please check for
usualy things like the latest sh compatible pd shell in your own
environment. Things like this are known to hinder compilation if
they ate not fully compatible with sh or are buggy.
Current build problem on (Mac) NetBSD, possibly BSDI and 386BSD:
pmake (e. g. NetBSD on MAC, possible other BNR2+pmake systems)
Following Makefile construction fails for no
apparent reason (at least to me)
doit:
$(MAKE) MAKE=\"$(MAKE)\" all
all:
@echo all done.
for the "make MAKE=make" call but not for "make" or
"make -e MAKE=make". Use the last form if you suffer
from that kind of make problems. (Easily detected
by failure to build with the message:
"don't know how to make make".
The known sh and some make pecularities have already been taken care of.
The pmake (in the BNR2 branches) problem seems to be real at the time of this
writing. If you know a portable(!) fix we'd like to hear from you.
Usually the vendor should fix these bugs in vital utilities.
We try to circumvent these bugs in a hopefully portable way.
If you can reproduce these bugs on your system please bug your
vendor/developer group to fix them. We are not trying anything fancy
in here (except for starting sub-makes) and we are shocked that even
the most common tools fail so miserably. By the time you get this
code the above utilities may already have been fixed. Hopefully one
day we do not have to cope with this kind of broken utilities.
Frank Kardel
William L. Jones <jones@chpc.utexas.edu>
Dennis Ferguson (Advanced Network Systems) <dennis@ans.net>
Lars Mathiesen (University of Copenhagen) <thorinn@diku.dk>
David Mills <mills@udel.edu>
Frank Kardel <Frank.Kardel@informatik.uni-erlangen.de>
Piete Brooks <Piete.Brooks@cl.cam.ac.uk>
-- and a cast of thousands -- see the COPYRIGHT file
16 November 1993
|
