d@0: d@0: Next: Installation on non-Unix systems, d@0: Previous: Installation and Customization, d@0: Up: Installation and Customization d@0:
FFTW comes with a configure program in the GNU style.
d@0: Installation can be as simple as:
d@0:
d@0:
./configure d@0: make d@0: make install d@0:d@0:
This will build the uniprocessor complex and real transform libraries
d@0: along with the test programs. (We recommend that you use GNU
d@0: make if it is available; on some systems it is called
d@0: gmake.) The “make install” command installs the fftw
d@0: and rfftw libraries in standard places, and typically requires root
d@0: privileges (unless you specify a different install directory with the
d@0: --prefix flag to configure). You can also type
d@0: “make check” to put the FFTW test programs through their paces.
d@0: If you have problems during configuration or compilation, you may want
d@0: to run “make distclean” before trying again; this ensures that
d@0: you don't have any stale files left over from previous compilation
d@0: attempts.
d@0:
d@0:
The configure script chooses the gcc compiler by default,
d@0: if it is available; you can select some other compiler with:
d@0:
./configure CC="<the name of your C compiler>" d@0:d@0:
The configure script knows good CFLAGS (C compiler flags)
d@0: for a few systems. If your system is not known, the configure
d@0: script will print out a warning. In this case, you should re-configure
d@0: FFTW with the command
d@0:
./configure CFLAGS="<write your CFLAGS here>" d@0:d@0:
and then compile as usual. If you do find an optimal set of
d@0: CFLAGS for your system, please let us know what they are (along
d@0: with the output of config.guess) so that we can include them in
d@0: future releases.
d@0:
d@0:
configure supports all the standard flags defined by the GNU
d@0: Coding Standards; see the INSTALL file in FFTW or
d@0: the GNU web page.
d@0: Note especially --help to list all flags and
d@0: --enable-shared to create shared, rather than static, libraries.
d@0: configure also accepts a few FFTW-specific flags, particularly:
d@0:
d@0:
--enable-portable-binary: Disable compiler optimizations that
d@0: would produce unportable binaries. Important: Use this if you are
d@0: distributing compiled binaries to people who may not use exactly the
d@0: same processor as you.
d@0:
d@0: --with-gcc-arch=arch: When compiling with gcc, FFTW
d@0: tries to deduce the current CPU in order to tell gcc what
d@0: architecture to tune for; this option overrides that guess
d@0: (i.e. arch should be a valid argument for gcc's
d@0: -march or -mtune flags). You might do this because the
d@0: deduced architecture was wrong or because you want to tune for a
d@0: different CPU than the one you are compiling with. You can use
d@0: --without-gcc-arch to disable architecture-specific tuning
d@0: entirely. Note that if --enable-portable-binary is enabled
d@0: (above), then we use -mtune but not -march, so the
d@0: resulting binary will run on any architecture even though it is
d@0: optimized for a particular one.
d@0:
d@0: --enable-float: Produces a single-precision version of FFTW
d@0: (float) instead of the default double-precision (double).
d@0: See Precision.
d@0:
d@0: --enable-long-double: Produces a long-double precision version of
d@0: FFTW (long double) instead of the default double-precision
d@0: (double). The configure script will halt with an error
d@0: message is long double is the same size as double on your
d@0: machine/compiler. See Precision.
d@0:
d@0: --enable-threads: Enables compilation and installation of the
d@0: FFTW threads library (see Multi-threaded FFTW), which provides a
d@0: simple interface to parallel transforms for SMP systems. By default,
d@0: the threads routines are not compiled.
d@0:
d@0: --enable-openmp: Like --enable-threads, but using OpenMP
d@0: compiler directives in order to induce parallelism rather than
d@0: spawning its own threads directly. Useful especially for programs
d@0: already employing such directives, in order to minimize conflicts
d@0: between different parallelization mechanisms. Use either
d@0: --enable-openmp or --enable-threads, not both; in either
d@0: case the multi-threaded FFTW interface/library (see Multi-threaded FFTW) is compiled (with different back ends).
d@0:
d@0: --with-combined-threads: By default, if --enable-threads
d@0: or --enable-openmp are used, the threads support is compiled
d@0: into a separate library that must be linked in addition to the main
d@0: FFTW library. This is so that users of the serial library do not need
d@0: to link the system threads libraries. If
d@0: --with-combined-threads is specified, however, then no separate
d@0: threads library is created, and threads are included in the main FFTW
d@0: library. This is mainly useful under Windows, where no system threads
d@0: library is required and inter-library dependencies are problematic.
d@0:
d@0: --enable-cell: Enables code to exploit the Cell processor
d@0: (see FFTW on the Cell Processor), assuming you have the Cell SDK.
d@0: By default, code for the Cell processor is not compiled.
d@0:
d@0: --disable-fortran: Disables inclusion of Fortran-callable
d@0: wrapper routines (see Calling FFTW from Fortran) in the standard
d@0: FFTW libraries. These wrapper routines increase the library size by
d@0: only a negligible amount, so they are included by default as long as
d@0: the configure script finds a Fortran compiler on your system.
d@0: (To specify a particular Fortran compiler foo, pass
d@0: F77=foo to configure.)
d@0:
d@0: --with-g77-wrappers: By default, when Fortran wrappers are
d@0: included, the wrappers employ the linking conventions of the Fortran
d@0: compiler detected by the configure script. If this compiler is
d@0: GNU g77, however, then two versions of the wrappers are
d@0: included: one with g77's idiosyncratic convention of appending
d@0: two underscores to identifiers, and one with the more common
d@0: convention of appending only a single underscore. This way, the same
d@0: FFTW library will work with both g77 and other Fortran
d@0: compilers, such as GNU gfortran. However, the converse is not
d@0: true: if you configure with a different compiler, then the
d@0: g77-compatible wrappers are not included. By specifying
d@0: --with-g77-wrappers, the g77-compatible wrappers are
d@0: included in addition to wrappers for whatever Fortran compiler
d@0: configure finds.
d@0:
d@0: --with-slow-timer: Disables the use of hardware cycle counters,
d@0: and falls back on gettimeofday or clock. This greatly
d@0: worsens performance, and should generally not be used (unless you don't
d@0: have a cycle counter but still really want an optimized plan regardless
d@0: of the time). See Cycle Counters.
d@0:
d@0: --enable-sse, --enable-sse2, --enable-altivec,
d@0: --enable-mips-ps:
d@0: Enable the compilation of SIMD code for SSE (Pentium III+), SSE2
d@0: (Pentium IV+), AltiVec (PowerPC G4+), or MIPS PS. SSE, AltiVec, and MIPS PS
d@0: only work with --enable-float (above), while SSE2 only works in double
d@0: precision (the default). The resulting code will still work on
d@0: earlier CPUs lacking the SIMD extensions (SIMD is automatically
d@0: disabled, although the FFTW library is still larger).
d@0: gcc, you may have to use the
d@0: -mabi=altivec option when compiling any code that links to FFTW,
d@0: in order to properly align the stack; otherwise, FFTW could crash when
d@0: it tries to use an AltiVec feature. (This is not necessary on MacOS X.)
d@0: gcc, you should use a version of gcc that
d@0: properly aligns the stack when compiling any code that links to FFTW.
d@0: By default, gcc 2.95 and later versions align the stack as
d@0: needed, but you should not compile FFTW with the -Os option or the
d@0: -mpreferred-stack-boundary option with an argument less than 4.
d@0: To force configure to use a particular C compiler foo
d@0: (instead of the default, usually gcc), pass CC=foo to the
d@0: configure script; you may also need to set the flags via the variable
d@0: CFLAGS as described above.
d@0:
d@0:
d@0:
d@0:
d@0: