-
A C compiler is required.
-
For GNU/Linux
The GNU C Compiler (gcc
) is recommended as the bytecode interpreter takes advantage of GCC-specific features to enhance performance. GCC is the standard compiler under Linux and many other systems. -
For BSDs
clang
is the default C compiler on BSDs - also works fine. -
For macOS
clang
is the default C compiler under macOS. If macOS complains no C compiler was installed while OCaml is building, please run commandxcode-select --install
to install command-line tools and required libraries and header files. -
For other Unix-like systems
It is recommended to usegcc
orclang
instead of the C compiler provided by the vendor of the system. -
For Windows
To produce native Windows executables from OCaml sources, you need to use the MSVC or Mingw-w64 ports of OCaml, described in file README.win32.adoc.
For a more Unix-like experience, you can use WSL, the Windows Subsystem for Linux, or the Cygwin environment. You will need the GCC compiler (packagegcc-core
orgcc
).
-
-
GNU
make
, as well as POSIX-compatibleawk
andsed
are required. -
A POSIX-compatible
diff
is necessary to run the test suite. -
If you do not have write access to
/tmp
, you should set the environment variableTMPDIR
to the name of some other temporary directory.
-
Under Cygwin, the
gcc-core
package is required.flexdll
is also necessary for shared library support. -
Binutils including
ar
andstrip
are required if your distribution does not already provide them with the C compiler.
From the top directory, do:
./configure
This generates the three configuration files Makefile.config
,
runtime/caml/m.h
and runtime/caml/s.h
.
The configure
script accepts options that can be discovered by running:
./configure --help
Some options or variables like LDLIBS may not be taken into account by the OCaml build system at the moment. Please report an issue if you discover such a variable or option and this causes troubles to you.
Examples:
-
Standard installation in
/usr/{bin,lib,man}
instead of/usr/local
: ./configure --prefix=/usr -
On a Linux x86-64 host, to build a 32-bit version of OCaml:
./configure --build=x86_64-pc-linux-gnu --host=i686-linux-gnu
-
For AIX 7.x with the IBM compiler
xlc
:./configure CC=xlc
By default, build is 32-bit. For 64-bit build, please set environment variable
OBJECT_MODE=64
for bothconfigure
andmake world
phases. Note, if this variable is set for only one phase, your build will break (ocamlrun
segfaults). -
For Solaris/Illumos on SPARC machines with Sun PRO compiler only 64-bit bytecode target is supported (32-bit fails due to alignment issues; the optimization is preset to
-O4
for inlining):./configure CC="cc -m64"
If something goes wrong during the automatic configuration, or if the generated files cause errors later on, then look at the template files:
Makefile.config.in Makefile.build_config.in runtime/caml/m.h.in runtime/caml/s.h.in
for guidance on how to edit the generated files by hand.
From the top directory, do:
make
This builds the OCaml compiler for the first time. This phase is fairly verbose; consider redirecting the output to a file:
make > make.log 2>&1 # in sh make >& make.log # in csh
To be sure everything works well, you can run the test suite that comes with the compiler. To do so, do:
make tests
You can now install the OCaml system. This will create the following commands (in the binary directory selected during autoconfiguration):
|
the batch bytecode compiler |
|
the batch native-code compiler (if supported) |
|
the runtime system for the bytecode compiler |
|
the parser generator |
|
the lexer generator |
|
the interactive, toplevel-based system |
|
a tool to make toplevel systems that integrate user-defined C primitives and OCaml code |
|
the source-level replay debugger |
|
generator of "make" dependencies for OCaml sources |
|
the documentation generator |
|
the execution count profiler |
|
the bytecode compiler in profiling mode |
From the top directory, become superuser and do:
make install
Installation is complete. Time to clean up. From the toplevel directory, do:
make clean
After installation, do not strip the ocamldebug
executables.
This is a mixed-mode executable (containing both compiled C
code and OCaml bytecode) and stripping erases the bytecode! Other
executables such as ocamlrun
can safely be stripped.
Read the "common problems" and "machine-specific hints" section at the end of this file.
Check the files m.h
and s.h
in runtime/caml/
.
Wrong endianness or alignment constraints in machine.h
will
immediately crash the bytecode interpreter.
If you get a "segmentation violation" signal, check the limits on the stack size
and data segment size (type limit
under csh or ulimit -a
under bash). Make
sure the limit on the stack size is at least 4M.
Try recompiling the runtime system with optimizations turned off (change
OC_CFLAGS
in runtime/Makefile
). The runtime system
contains some complex, atypical pieces of C code which can uncover bugs in
optimizing compilers. Alternatively, try another C compiler (e.g. gcc
instead
of the vendor-supplied cc
).
You can also use the debug version of the runtime system which is
normally built and installed by default. Run the bytecode program
that causes troubles with ocamlrund
rather than with ocamlrun
.
This version of the runtime system contains lots of assertions
and sanity checks that could help you pinpoint the problem.
-
The Makefiles assume that make executes commands by calling
/bin/sh
. They won’t work if/bin/csh
is called instead. You may have to unset theSHELL
environment variable, or set it to/bin/sh
. -
On some systems, localization causes build problems. You should try to set the C locale (
export LC_ALL=C
) before compiling if you have strange errors while compiling OCaml. -
In the unlikely case that a platform does not offer all C99 float operations that the runtime needs, a configuration error will result. Users can work around this problem by calling
configure
with the flag--enable-imprecise-c99-float-ops
. This will enable simple but potentially imprecise implementations of C99 float operations. Users with exacting requirements for mathematical accuracy, numerical precision, and proper handling of mathematical corner cases and error conditions may need to consider running their code on a platform with better C99 support.