summaryrefslogtreecommitdiff
path: root/doc/flags.html
blob: 2f890680c95ae76e57934e8c347dfe0500b48963 (plain)
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
196
197
198
199
200
201
202
203
<html>
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="Content-Language" content="en" />
    <title>skalibs: configuration flags</title>
    <meta name="Description" content="skalibs: configuration flags" />
    <meta name="Keywords" content="skalibs build compilation configuration flags options" />
    <!-- <link rel="stylesheet" type="text/css" href="//skarnet.org/default.css" /> -->
  </head>
<body>

<p>
<a href="index.html">skalibs</a><br />
<a href="//skarnet.org/software/">Software</a><br />
<a href="//skarnet.org/">skarnet.org</a>
</p>

<h1> skalibs configuration flags </h1>

<p>
 The skalibs <tt>./configure</tt> script comes with a few
uncommon options; this page explains what they are for.
</p>

<a name="slashpackage"><h3> --enable-slashpackage[=<em>sproot</em>] </h3></a>

<p>
 This flag tells configure that you want to install skalibs according to
the <a href="https://cr.yp.to/slashpackage.html">slashpackage convention</a>.
If you enable it, and $v is the version of skalibs you're compiling,
<tt>make install</tt> will install the skalibs header files in
<tt>/package/prog/skalibs-$v/include</tt>, the static libraries in
<tt>/package/prog/skalibs-$v/library</tt>, the dynamic libraries in
<tt>/package/prog/skalibs-$v/library.so</tt> and the data files in
<tt>/package/prog/skalibs-$v/etc</tt>, all prefixed by <em>sproot</em>
if present.
</p>

<p>
  It will also prepend the default path with <tt>/command</tt>, unless an
explicit default path has been given via the
<a href="#defaultpath"><tt>--with-default-path</tt></a> option.
</p>

<p>
 Additionally, it will add two more "make" targets:
</p>

<ul>
 <li> <tt>make update</tt> will update the <tt>/package/prog/skalibs</tt>
symbolic link to point to <tt>skalibs-$v</tt> </li>
 <li> <tt>make -L global-links </tt> will make links from <tt>/library.so</tt>
to the installed skalibs shared libraries. </li>
</ul>

<p>
 If this option is not given, no slashpackage support will be provided.
</p>

<a name="clockistai"><h3> --enable-tai-clock </h3></a>

<p>
 To understand what this flag is about - and the next two flags too - you
should start by reading
<a href="https://www.madore.org/~david/computers/unix-leap-seconds.html">this
page about Unix time</a>,
which <a href="https://www.madore.org/~david/">David Madore</a> wrote after
a long and fairly complete discussion we had on the subject. You can also
read <a href="https://cr.yp.to/proto/utctai.html">what DJB says about Unix time</a>.
Unfortunately, when he says "the POSIX rules are so outrageously dumb (...)
that no self-respecting engineer would obey them", DJB is wrong: a lot of
people follow the POSIX rules. Or maybe he's right... and there are very,
very few self-respecting engineers.
</p>

<p>
 Basically, when you configure a Unix system, there are essentially two
ways to deal with your system clock.
</p>

<ol>
 <li> You can set your system clock to TAI-10, which is the "right", but
uncommon, thing to do:
  <ul>
   <li> &uarr; The main advantage of this setup is that it makes your system clock
<em>linear</em>. In other words,
<a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/gettimeofday.html">gettimeofday()</a>
becomes suitable for both timestamping (which needs absolute time) and timeout
computations (which need reliable interval measurements); if your clock is
accurate enough, it can function as both a wall clock and a stopwatch.
This simplifies keeping track of the current time <strong>considerably</strong>,
and makes event loop handling (with functions such as
<a href="libstddjb/iopause.html">iopause()</a>) trivial. </li>
   <li> &uarr; skalibs uses TAI internally; setting your system clock to TAI-10
saves a lot of conversions and makes time computations with skalibs more
efficient. </li>
   <li> &rarr; skalibs-aware software will display GMT or local time properly in
every case, but you have to
use the <tt>right/</tt> timezones, from Arthur David Olson's timezone
library, to prevent your other software from being confused by a TAI-10 system clock.
If you do not use <tt>right/</tt> timezones, utilities such as <tt>date</tt>
will not compute the proper time - they will have an offset of 24 seconds
or so. </li>
   <li> &darr; This setup is arguably not SUSv4 conformant (a strict
interpretation of Single Unix requires the system clock to be set to UTC). </li>
   <li> &darr; This setup is <em>not</em> compatible with
<a href="https://en.wikipedia.org/wiki/Ntpd">ntpd</a>. <tt>ntpd</tt>'s design
is flawed: it makes the mistake of setting the system clock itself - instead
of simply making the computed time available to other programs, one of which
could set the system clock - and it always sets it to UTC. (The
<a href="//skarnet.org/software/s6-networking/">s6-networking</a>
package provides alternate ways to synchronize your clock, though.) </li>
  </ul>
 </li>
 <li> You can set your system clock to UTC, which is the common, strictly
POSIX setup:
  <ul>
   <li> &uarr; This is strictly SUSv4-compliant. Most Unix machines all over
the world are set up like this. </li>
   <li> &uarr; This is compatible with ntpd. </li>
   <li> &rarr; You should use <tt>posix/</tt> time zones in that case,
not <tt>right/</tt> time zones. </li>
   <li> &darr; skalibs time computations will take a bit more processing power. </li>
   <li> &darr; Most importantly, you forsake all linearity - and even monotonicity
- on your system clock, which can now only be used as a wall clock,
<em>not</em> as a stopwatch. skalibs will try its best to do accurate time
computations, but there's no way <tt>gettimeofday()</tt> can be relied on
when a leap second is nearby; you have to use CLOCK_MONOTONIC as a stopwatch
for accurate interval measurement. </li>
  </ul>
 </li>
</ol>

<p>
 Use <tt>--enable-tai-clock</tt> if your system clock is set to TAI-10.
I generally recommend this setup
for computers you have full control on, on which you install and tweak
the software your way, like manually administered servers or embedded
boxes. If you do not run ntpd and do not mind breaking POSIX, it is the
sensible choice.
</p>

<p>
 Do not use this option if your system clock is set to UTC, i.e. if
you're in none of the above cases: you are a
POSIX freak, or your Unix distribution is running ntpd for you, or
other software is assuming you're on UTC. This is the default.
</p>

<a name="noipv6"><h3> --disable-ipv6 </h3></a>

<p>
 If you set this option, then skalibs will be compiled without IPv6 support,
even if your target architecture supports it. This can significantly
reduce the size of your networking applications if they don't need IPv6
support.
</p>

<p>
 If you don't set this option, then skalibs will include IPv6 support in the
relevant networking functions if and only if the target architecture supports it.
This is the default, and it is safe.
</p>

<a name="defaultpath"><h3> --with-default-path=<em>path</em> </h3></a>

<p>
 The <a href="libstddjb/djbunix.html">execvep()</a> function uses
the value of the PATH environment variable as its executable search path.
Specifying this option to configure tells execvep() what executable
search path to use when PATH is undefined (which should not happen
often anyway).
 The default is <tt>/usr/bin:/bin</tt>, which is usually safe.
</p>

<a name="sysdep"><h3> --enable-sysdep-devurandom=yes </h3></a>

<p>
 When compiling natively, skalibs probes the build system for <em>sysdeps</em>,
i.e. system-specific behaviours that influence the way skalibs must
implement certain interfaces. This autodetection can be overriden on the
configure command line: for a sysdep named <em>K</em>, if you want to
enforce the value <em>V</em>, you can use <tt>--enable-sysdep-<em>K</em>=<em>V</em></tt>
as a configure option.
</p>

<p>
(This is similar to the <tt>ac_cv_foobar_<em>K</em>=<em>V</em></tt> environment
variable mechanism in autotools.)
</p>

<p>
 When <a href="crosscompile.html">cross-compiling</a>, there are a few sysdeps
that <em>cannot</em> be autodetected and have to be provided manually on the
command line. The <tt>devurandom</tt> sysdep, which encodes the existence of
a functional <tt>/dev/urandom</tt> device on the target, is one of those.
<tt>--enable-sysdep-devurandom=yes</tt> tells skalibs to assume that there is
such a device it can rely on for random number generation.
</p>

</body>
</html>