This is a generic INSTALL file for utilities distributions. Some features specific to `gcal' have been added. To compile this package: 0. You can set your private/local/site depending options in the make variables DEFINES, DEFINES2 and DEFINES3. Choose and set these options EITHER in the files "gcal_def.h" and "gcal_tai.h" OR in the appropriate template makefile `Makefile.in' (of which the configure script generates the site specific `Makefile') before compiling `gcal'; OR use the --enable-FEATURE / --disable-FEATURE arguments of configure (try: configure --help for an overview)! Inspect the README files for some more information. 1. Configure the package for your system. In the directory that this file is in, type `./configure'. If you're using `csh' on an old version of System V, you might need to type `sh configure' instead to prevent `csh' from trying to execute `configure' itself. If you are using Ultrix, you might need to type `sh5 configure' to avoid bugs in /bin/sh. Note that 'sh -x configure' may give different results than 'sh configure', making it difficult to debug configure scripts. The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation, and creates the Makefile(s) (one in each subdirectory of the source directory). In some packages it creates a C header file containing system-dependent definitions. It also creates a file `config.status' that you can run in the future to recreate the current configuration. Running `configure' takes a minute or two. While it is running, it prints some messages that tell what it is doing. If you don't want to see the messages, run `configure' with its standard output redirected to `/dev/null'; for example, `./configure >/dev/null'. To compile the package in a different directory from the one containing the source code, you must use a version of `make' that supports the VPATH variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run `configure'. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. If for some reason `configure' is not in the source code directory that you are configuring, then it will report that it can't find the source code. In that case, run `configure' with the option `--srcdir=DIR', where DIR is the directory that contains the source code. By default, `make install' will install the package's files in /usr/local/bin, /usr/local/lib, /usr/local/man, etc. You can specify an installation prefix other than /usr/local by giving `configure' the option `--prefix=PATH'. Alternately, you can do so by consistently giving a value for the `prefix' variable when you run `make', e.g., make prefix=/usr/gnu make prefix=/usr/gnu install You can specify separate installation prefixes for architecture-specific files and architecture-independent files. If you give `configure' the option `--exec-prefix=PATH' or set the `make' variable `exec_prefix' to PATH, the package will use PATH as the prefix for installing programs and libraries. Data files and documentation will still use the regular prefix. Normally, all files are installed using the regular prefix. Another `configure' option is useful mainly in `Makefile' rules for updating `config.status' and `Makefile'. The `--no-create' option figures out the configuration for your system and records it in `config.status', without actually configuring the package (creating `Makefile's and perhaps a configuration header file). Later, you can run `./config.status' to actually configure the package. You can also give `config.status' the `--recheck' option, which makes it re-run `configure' with the same arguments you used before. This option is useful if you change `configure'. `configure' ignores any other arguments that you give it. If your system requires unusual options for compilation or linking that `configure' doesn't know about, you can give `configure' initial values for some variables by setting them in the environment. In Bourne-compatible shells, you can do that on the command line like this: CC='gcc -traditional' DEFS=-D_POSIX_SOURCE ./configure For csh compatible shells, you can do something like this: (setenv CC 'gcc -traditional' ; ./configure) The `make' variables that you might want to override with environment variables when running `configure' are: (For these variables, any value given in the environment overrides the value that `configure' would choose:) CC C compiler program. Default is `cc', or `gcc' if `gcc' is in your PATH. INSTALL Program to use to install files. Default is `install-sh' (in package), `cp' otherwise. If you have an non-standard `install', use INSTALL="cp -p" (For these variables, any value given in the environment is added to the value that `configure' chooses:) DEFS Options configure has found, in the form `-Dfoo -Dbar ...' CFLAGS Compiler options, such as `-O -g ...' LIBS Libraries to link with, in the form `-lfoo -lbar ...' If you need to do unusual things to compile the package, we encourage you to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the README so we can include them in the next release. 2. Type `make' to compile the package. If you want, you can override the `make' variables CFLAGS and LDFLAGS like this: make CFLAGS=-O2 LDFLAGS=-s 3. The package comes with self-tests. If you want to run them, type `make check'. 4. Type `make install' to install programs, data files, and documentation. The man pages are installed by default with an extension `.1' (one). If you want the extension `.l' (lower case L) use: make manext=l install If you are using csh or tcsh, you must type `rehash' after `make install' to make sure that the command `gcal' will invoke the new executable. 5. You can remove the program binaries and object files from the source directory by typing `make clean'. To also remove the Makefile(s), the header file containing system-dependent definitions (if the package uses one), and `config.status' (all the files that `configure' created), type `make distclean'. The file `configure.in' is used as a template to create `configure' by a program called `autoconf'. You will only need it if you want to regenerate `configure' using a newer version of `autoconf'. 6. In case `gcal' is compiled using libtermcap/libtermlib and should produce ugly runtime errors, we have to work around the Termcap bug. Reconfigure the package with additional "--disable-term" argument and create the binary again (`make -s' or `make -s installbin'). 7. For an overview of all Makefile targets, type `make help'. 8. Special targets - For MS-DOS, OS/2, Windows NT, VMS, Acorn, Atari, Amiga, Primos, use the makefile(s) or command file(s) provided in the appropriate subdirectory and edit the LIB, INCLUDE, []FLAGS and CC entries to reflect your local system. - On MS-DOS, Microsoft-C v5.0 is buggy in some cases and could die. Don't use that compiler version, use version 5.1 or newer. - On MS-DOS, the library function `qsort()' of Microsoft-C v5.1 and v6.0 seems to be realized with very poor performance. If large numbers of fixed date warnings messages are processed and these warning texts are internally presorted in the resource file(s) except some very few ones, this `qsort()' function becomes very busy and you have to wait a long time before all sorting is done. Avoid to use these Microsoft compilers, use Borland-C++ 3.1 or newer instead! - On MS-DOS, the library function `malloc()' of Borlands Turbo-C++ 1.0 (and perhaps of Turbo-C 2.0 too) seems to have a serious bug. Avoid to use these compilers, use Borland-C++ 3.1 or newer instead! - On MS-DOS, Zortech-C v2.14 is buggy in some cases. Use a newer version. - If your system is a pure BSD system but incorrectly links string.h to strings.h, you may get undefined str* symbols. Try recompiling with make clean make CFLAGS="-USTDC_HEADERS -UHAVE_STRING_H" - On Ultrix, /bin/sh is too buggy. Use "sh5 configure" instead of "configure". - On Xenix, some preprocessors do not define M_XENIX. You may have to do: DEFS='-DM_XENIX' ./configure - On Xenix 2.3.2 for 286, do: make xenix_286 - On Coherent, do: make coherent - On some versions of NeXT, either "cc -finline-functions" or "cc -O4" is broken. Use "cc -O" instead. - On Solaris 2.1 for x86, the January 1993 "OEM" compiler release generates bad code. This is fixed in the June 1993 "FCS" release. - On Solaris 2.4 use gawk or perl instead of nawk. - On Sparc with SunOS 4.1.1 and the SC1.0 compiler, the optimizer works up to -O3 but -O4 does not work. - Some systems could use index() and rindex() instead of strchr() and strrch(). If the linker is unable to detect these objects in the standard libs, add "-lbsd" or "-lucb" to LIBS and recompile the source. - On dnix 5.3 2.2 cc version 2.37c is buggy. Version 2.38d works. - On an Alliant running Concentrix, cc (even without optimization) generates incorrect code. You have to use gcc. - On Cray running CSOS 1.0 with compiler version dev-125, you must compile with the flag "-hnoopt" to avoid an optimizer bug. - On HPUX, configure can't find a correct install. Use: INSTALL=/usr/local/bin/bsdinst ./configure