GSL - GNU Scientific Library
============================

Installation Instructions
=========================

GSL follows the standard GNU installation procedure.  To compile GSL
you will need an ANSI C-compiler.  After unpacking the distribution
the Makefiles can be prepared using the configure command,

  ./configure

You can then build the library by typing,

  make

Both static and shared versions of the libraries will be compiled by
default.  Compilation of shared libraries can be turned off by
specifying the `--disable-shared' option to `configure', e.g.
  
  ./configure --disable-shared

This is recommended if you encounter problems building the library,
because some platforms do not support shared libraries.

For notes about problems with specific platforms and compilers see the
next section of this file (below).

An extensive test suite is available.  It can be invoked with "make
check" in each directory.  All tests can be run together with "make
check" at the top level.  The test output should be directed to a file
rather than a terminal, with the command,

   make check > log 2>&1

since it is several megabytes in size.

If you run "make check" and get some failures, please see the notes on
platform specific problems below.  If you find failures that are not
mentioned, please report them.

The library can be installed using the command,

  make install

The default install directory prefix is /usr/local.  Consult the
"Further Information" section below for instructions on installing the
library in another location or changing other default compilation
options.

                    ------------------------------

Platform Specific Compilation Notes
===================================

This section documents any known issues with installing GSL on
specific platforms.

Hints for any platform
======================

1) If there are problems building the library try using

        ./configure --disable-shared

This will turn off the compilation of shared libraries and may allow
the build process to complete successfully.  

If you get any problems try this first.

2) With gcc-2.95/2.96 the tests fail in the eigen/ directory.  This is
due to a compiler optimization bug which causes errors in the
manipulation of complex numbers.  Do not use the library if you
encounter this problem.

This is fixed in more recent versions of gcc.  Compiling without
optimisation will work around the bug.

3) Attempts to run 'strip' on the static library libgsl.a will probably
produce a broken library (it is known to happen with GNU binutils
strip, and probably affects others too). The libgsl.a ar archive made
by libtool contains files with the same filenames from different
directories, and this causes the strip program to overwrite these
archive entries.  If you need to produce a compact version of the
library compile without -g instead of using strip.

make install-strip does not work, due to a minor problem with autoconf
which is fixed in the 2.5 development version of autoconf.  In the
meantime compile without -g instead if you need to reduce the file size.

Hints for AIX
=============

For compilation problems with the native compiler xlc, try disabling
shared libraries,

    setenv CC 'xlc'
    setenv CFLAGS '-O -qmaxmem=8192'
    ./configure --disable-shared
    make

If you get the error,

   ld: 0711-781 ERROR: TOC overflow. 

you can try building the library with a larger linker
table-of-contents by setting LDFLAGS before compilation,

   LDFLAGS="-Wl,-bbigtoc" ./configure


Hints for Compaq/DEC Alpha
==========================

The library should compile successfully with Compaq's C compiler using
the -std and -ieee options.  Use

    CC=cc ./configure    
    make CFLAGS="-std -ieee"

to build the library this way.

Use GNU tar to unpack the tar file, as Tru64 tar gives an error
halfway through.

Hints for DOS
=============

When using DJGPP The default stack size of 512k may be insufficient for
the specfunc tests and will cause them to crash.  To increase the
stack size by a suitable amount use,

  	stubedit test.exe minstack=1536k

on the executable and then rerun it manually.  (5/01: The specfunc
tests have been rewritten to use less stack space now).


Hints for HP-UX
===============

The default mode of the HP-UX C compiler does not use ANSI C.

To compile GSL you need to select ANSI C mode with the following
configuration option:

      CFLAGS="-Ae -O"  ./configure


Hints for Intel (Pentium)
========================

For the Pentium 4 with GCC-3.2 the flags,

      CFLAGS="-O2 -march=pentium4 -mfpmath=sse -msse2"

increase performance by 33% (reported by Sam Halliday <fommil@yahoo.ie>)

Hints for IRIX (SGI)
====================

The library should be compiled with the following option,

        -OPT:IEEE_NaN_inf=ON 

to ensure correct IEEE arithmetic.  The tests in sys/ will fail
without this option.  The older deprecated option
-OPT:IEEE_comparisons=ON will also work.

The 32 bit IRIX compiler gives warnings about "long double" not being
supported. These can be ignored or turned off with,

   CFLAGS="-woff 728" ./configure

or 

   make CFLAGS="-woff 728"

The compiler also gives warnings about certain libraries that are "not
used for resolving any symbol". This is harmless and the warnings can
be ignored.

You may get warnings about " /usr/bin/ld: arg list too long" when
building shared libraries.  If so, try increasing the ncargs kernel
parameter with the systune(1m) command.

For 64-bit compilation use the following options,

  CC=cc CFLAGS="-64" LDFLAGS="-64" ./configure

or for gcc

  CFLAGS="-mabi-64" LDFLAGS="-mabi=64 -mips4 -L/usr/local/lib/mabi=64"

Hints for MacOS X
=================

Note that GSL contains files with filenames of 32 characters or more.
Therefore you need to be careful in unpacking the tar file, as some
MacOS applications such as Stuffit Expander will truncate filenames to
31 characters.  Using GNU tar and gunzip directly is the safe way to
unpack the distribution.

There are problems with dynamic linker, so the library should be
compiled with,

  ./configure --disable-shared

To build shared libraries you can install MacOS X versions of libtool,
automake and autoconf, and then reconfigure:

  1. Get the fink packaging tool (http://fink.sourceforge.net)
  2, Install fink's libtool14, automake, autoconf25.
  3. Regenerate GSL's configuration using ./autogen.sh in the 
     top-level directory.
  4. ./configure, make

To avoid warnings about long-double, use the flag

  CFLAGS="-Wno-long-double ....(other options here)"

in addition to the normal compilation options.

Hints for Microsoft Windows
===========================

With Microsoft Visual C++, see the directory msvc/ in the CVS repository.

Hints for OpenBSD
=================

As of July 2001 the OpenBSD log1p() function on i386 causes failures
in the gsl complex tests.  The configure script has been hardcoded to
substitute gsl_log1p instead on OpenBSD.  The log1p() bug has been
reported and so may be fixed in future versions of OpenBSD.

Hints for OS/2
==============

The configure script fails to detect the function 'isnan', leading to
a slew of errors 'isnan redefined'.

To work around this problem, run configure and edit the resulting
config.h file to comment out the line which defines HAVE_ISINF.

Hints for PowerPC
=================

F J Frankin <MEP95JFF@sheffield.ac.uk> reported on the gsl-discuss
mailing list that some early versions of GCC-2.95 have a problem with
long argument lists on PPC architecture, and this prevents GSL from
compiling correctly (e.g. the test program in the blas directory gives
a segmentation fault when run).  This problem is fixed in recent
versions of GCC.  GSL now includes an autoconf test which detects the
problem.

Hints for Solaris
=================

Some warnings about "end of loop code not reached". These can be
ignored -- they come from the do { ... ; return ; } while(0) statement
in the GSL_ERROR macro.

                    ------------------------------

Further information on the standard GNU installation procedure
==============================================================

The sections below describe the general features of the standard GNU
installation procedure.

Basic Installation
==================

   These are generic installation instructions.

   The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation.  It uses
those values to create a `Makefile' in each directory of the package.
It may also create one or more `.h' files containing system-dependent
definitions.  Finally, it creates a shell script `config.status' that
you can run in the future to recreate the current configuration, a file
`config.cache' that saves the results of its tests to speed up
reconfiguring, and a file `config.log' containing compiler output
(useful mainly for debugging `configure').

   If you need to do unusual things to compile the package, please try
to figure out how `configure' could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they can
be considered for the next release.  If at some point `config.cache'
contains results you don't want to keep, you may remove or edit it.

   The file `configure.in' is used to create `configure' by a program
called `autoconf'.  You only need `configure.in' if you want to change
it or regenerate `configure' using a newer version of `autoconf'.

The simplest way to compile this package is:

  1. `cd' to the directory containing the package's source code and type
     `./configure' to configure the package for your system.  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.

     Running `configure' takes a while.  While running, it prints some
     messages telling which features it is checking for.

  2. Type `make' to compile the package.

  3. Optionally, type `make check' to run any self-tests that come with
     the package.

  4. Type `make install' to install the programs and any data files and
     documentation.

  5. You can remove the program binaries and object files from the
     source code directory by typing `make clean'.  To also remove the
     files that `configure' created (so you can compile the package for
     a different kind of computer), type `make distclean'.  There is
     also a `make maintainer-clean' target, but that is intended mainly
     for the package's developers.  If you use it, you may have to get
     all sorts of other programs in order to regenerate files that came
     with the distribution.

Compilers and Options
=====================

   Some systems require unusual options for compilation or linking that
the `configure' script does not know about.  You can give `configure'
initial values for variables by setting them in the environment.  Using
a Bourne-compatible shell, you can do that on the command line like
this:
     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure

Or on systems that have the `env' program, you can do it like this:
     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure

Compiling For Multiple Architectures
====================================

   You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory.  To do this, 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
the `configure' script.  `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.

   If you have to use a `make' that does not supports the `VPATH'
variable, you have to compile the package for one architecture at a time
in the source code directory.  After you have installed the package for
one architecture, use `make distclean' before reconfiguring for another
architecture.

Installation Names
==================

   By default, `make install' will install the package's files in
`/usr/local/bin', `/usr/local/man', etc.  You can specify an
installation prefix other than `/usr/local' by giving `configure' the
option `--prefix=PATH'.

   You can specify separate installation prefixes for
architecture-specific files and architecture-independent files.  If you
give `configure' the option `--exec-prefix=PATH', the package will use
PATH as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.

   If the package supports it, you can cause programs to be installed
with an extra prefix or suffix on their names by giving `configure' the
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.

Optional Features
=================

   Some packages pay attention to `--enable-FEATURE' options to
`configure', where FEATURE indicates an optional part of the package.
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
is something like `gnu-as' or `x' (for the X Window System).  The
`README' should mention any `--enable-' and `--with-' options that the
package recognizes.

   For packages that use the X Window System, `configure' can usually
find the X include and library files automatically, but if it doesn't,
you can use the `configure' options `--x-includes=DIR' and
`--x-libraries=DIR' to specify their locations.

Specifying the System Type
==========================

   There may be some features `configure' can not figure out
automatically, but needs to determine by the type of host the package
will run on.  Usually `configure' can figure that out, but if it prints
a message saying it can not guess the host type, give it the
`--host=TYPE' option.  TYPE can either be a short name for the system
type, such as `sun4', or a canonical name with three fields:
     CPU-COMPANY-SYSTEM

See the file `config.sub' for the possible values of each field.  If
`config.sub' isn't included in this package, then this package doesn't
need to know the host type.

   If you are building compiler tools for cross-compiling, you can also
use the `--target=TYPE' option to select the type of system they will
produce code for and the `--build=TYPE' option to select the type of
system on which you are compiling the package.

Sharing Defaults
================

   If you want to set default values for `configure' scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like `CC', `cache_file', and `prefix'.
`configure' looks for `PREFIX/share/config.site' if it exists, then
`PREFIX/etc/config.site' if it exists.  Or, you can set the
`CONFIG_SITE' environment variable to the location of the site script.
A warning: not all `configure' scripts look for a site script.

Operation Controls
==================

   `configure' recognizes the following options to control how it
operates.

`--cache-file=FILE'
     Use and save the results of the tests in FILE instead of
     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
     debugging `configure'.

`--help'
     Print a summary of the options to `configure', and exit.

`--quiet'
`--silent'
`-q'
     Do not print messages saying which checks are being made.

`--srcdir=DIR'
     Look for the package's source code in directory DIR.  Usually
     `configure' can determine that directory automatically.

`--version'
     Print the version of Autoconf used to generate the `configure'
     script, and exit.

`configure' also accepts some other, not widely useful, options.

