skalibs
Software
skarnet.org

skalibs compilation flags

Starting with release 1.0.0, skalibs can be configured via certain compilation flags and options. A flag is an empty file in the conf-compile/ subdirectory of skalibs, with a name that starts with flag-. To set flag-foobar, perform touch conf-compile/flag-foobar before the build; to clear flag-foobar, remove the file.

flag-allstatic

The flag-allstatic flag is supported by skalibs. If set, no .so libraries will be made, and the .a libraries will not be PIC. If clear, .so libraries will be made along .a libraries, and the latter ones will be PIC as well.

flag-slashpackage

The flag-slashpackage flag is also supported by skalibs. If it is set (default), a slashpackage installation will be assumed. If it is clear, a FHS installation will be assumed.

flag-replace-libc

If flag-replace-libc is set, then the low-level components of libstddjb, such as byte_copy(), will be built using independent, failsafe implementations; skalibs will avoid relying on the libc when possible.

If flag-replace-libc is clear, then native libc primitives such as memmove() will be used for the low-levels components of libstddjb. This is the default.

This flag should be set if your libc has known bugs or you are uncertain of it for some reason. Standard libcs on modern systems have been thoroughly tested, so it's usually safe, and faster, to stick to the default.

flag-clockistai

To understand what this flag is about - and the next three flags too - you should start by reading this page about Unix time, which David Madore wrote after a long and fairly complete discussion we had on the subject. You can also read what DJB says about Unix time. 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.

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

  1. You can set your system clock to TAI-10, which is the "right", but uncommon, thing to do:
  2. You can set your system clock to UTC, which is the common, strictly POSIX setup:

Set flag-clockistai 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.

Clear flag-clockistai if your system clock is set to UTC. Use this setting 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.

flag-tzisright

This flag tells skalibs whether or not you're using Olson's time library, i.e. "right/" timezones.

Normally, if you set flag-clockistai, you should also set up your timezone to a "right/" one, and set flag-tzisright. And if you clear flag-clockistai, you should also use a POSIX timezone, and clear flag-tzisright. flag-clockistai and flag-tzisright should always have the same value.

But some C libraries do not support the Olson time library's timezone format, and just do not provide the "right/" timezones! For instance, the (otherwise excellent) uClibc, an alternative libc for Linux, only supports POSIX timezones. And you might want to use such a libc, and still set up your clock to TAI-10, for instance in embedded environments where accurate timekeeping is important. In such cases, you'll set up a POSIX timezone, set flag-clockistai, and clear flag-tzisright.

Be aware that setting your system clock to TAI-10 without having a "right/" timezone will cause non-skalibs-using software to display local time incorrectly; in such a setup, only skalibs-using software will understand what is going on and do the proper computations to display the correct local time. Keep your settings as consistent as possible.

By default, flag-tzisright is clear, as is flag-clockistai.

flag-usert

Single Unix v4 describes gettimeofday() as obsolescent, and recommends the use of clock_gettime() with the CLOCK_REALTIME option instead. However:

If flag-usert is set, the taia_now() and taia_setnow() functions for getting and setting time will be based on the clock_gettime() and clock_settime() functions.

If flag-usert is clear, the old-school gettimeofday() and settimeofday() interfaces will be used. This is the default, and it's safe.

flag-usemon

Unless you have an accurate hardware system clock and you set it on a linear time scale such as TAI-10 instead of UTC (see above), it is generally a bad idea to trust the system clock for precise time interval measurements. Single Unix recommends the use of clock_gettime() with the CLOCK_MONOTONIC option to do such measurements: a stopwatch, not a wall clock. However:

If flag-usemon is set, then the absolute time given by the taia_now() call will be computed with CLOCK_MONOTONIC. This will ensure precise time arithmetic but may drift away from the system clock.

If flag-usemon is clear, taia_now() will return a time based on the system clock, and not use CLOCK_MONOTONIC. This is the default.

flag-noipv6

If this flag is set, 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.

If this flag is clear, then skalibs will include IPv6 support in the relevant networking functions, if the target architecture supports it. The safe option is to let this flag clear.

flag-forcedevr

If this flag is set, then the automatic sysdep tests will assume the target architecture has a working /dev/random and will skip its autodetection.

If this flag is clear, then /dev/random will be autodetected and tested; if entropy generation is low on the host, the compilation process might hang for several minutes. It is safe to let this flag clear; it should only be set to speed up the compilation process in a known environment and for testing purposes.

If skalibs is being cross-compiled, this flag obviously has no effect: the presence of a working /dev/random is read from the user-provided sysdeps.