1065 lines
28 KiB
HTML
1065 lines
28 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of OCAMLOPT</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>OCAMLOPT</H1>
|
|
Section: User Commands (1)<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<P>
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
<P>
|
|
ocamlopt - The OCaml native-code compiler
|
|
<P>
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
<P>
|
|
<B>ocamlopt</B>
|
|
|
|
[
|
|
<I>options</I>
|
|
|
|
]
|
|
<I>filename</I> ...
|
|
|
|
<P>
|
|
<B>ocamlopt.opt</B>
|
|
|
|
(same options)
|
|
<P>
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<P>
|
|
The OCaml high-performance
|
|
native-code compiler
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
compiles OCaml source files to native code object files and link these
|
|
object files to produce standalone executables.
|
|
<P>
|
|
The
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
command has a command-line interface very close to that
|
|
of
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1).
|
|
|
|
It accepts the same types of arguments and processes them
|
|
sequentially, after all options have been processed:
|
|
<P>
|
|
Arguments ending in .mli are taken to be source files for
|
|
compilation unit interfaces. Interfaces specify the names exported by
|
|
compilation units: they declare value names with their types, define
|
|
public data types, declare abstract data types, and so on. From the
|
|
file
|
|
<I>x</I>.mli,
|
|
|
|
the
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
compiler produces a compiled interface
|
|
in the file
|
|
<I>x</I>.cmi.
|
|
|
|
The interface produced is identical to that
|
|
produced by the bytecode compiler
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1).
|
|
|
|
<P>
|
|
Arguments ending in .ml are taken to be source files for compilation
|
|
unit implementations. Implementations provide definitions for the
|
|
names exported by the unit, and also contain expressions to be
|
|
evaluated for their side-effects. From the file
|
|
<I>x</I>.ml,
|
|
|
|
the
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
compiler produces two files:
|
|
<I>x</I>.o,
|
|
|
|
containing native object code, and
|
|
<I>x</I>.cmx,
|
|
|
|
containing extra information for linking and
|
|
optimization of the clients of the unit. The compiled implementation
|
|
should always be referred to under the name
|
|
<I>x</I>.cmx
|
|
|
|
(when given a .o file,
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
assumes that it contains code compiled from C, not from OCaml).
|
|
<P>
|
|
The implementation is checked against the interface file
|
|
<I>x</I>.mli
|
|
|
|
(if it exists) as described in the manual for
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1).
|
|
|
|
<P>
|
|
Arguments ending in .cmx are taken to be compiled object code. These
|
|
files are linked together, along with the object files obtained
|
|
by compiling .ml arguments (if any), and the OCaml standard
|
|
library, to produce a native-code executable program. The order in
|
|
which .cmx and .ml arguments are presented on the command line is
|
|
relevant: compilation units are initialized in that order at
|
|
run-time, and it is a link-time error to use a component of a unit
|
|
before having initialized it. Hence, a given
|
|
<I>x</I>.cmx
|
|
|
|
file must come
|
|
before all .cmx files that refer to the unit
|
|
<I>x</I>.
|
|
|
|
<P>
|
|
Arguments ending in .cmxa are taken to be libraries of object code.
|
|
Such a library packs in two files
|
|
<I>lib</I>.cmxa
|
|
|
|
and
|
|
<I>lib</I>.a
|
|
|
|
a set of object files (.cmx/.o files). Libraries are build with
|
|
<B>ocamlopt -a</B>
|
|
|
|
(see the description of the
|
|
<B>-a</B>
|
|
|
|
option below). The object
|
|
files contained in the library are linked as regular .cmx files (see
|
|
above), in the order specified when the library was built. The only
|
|
difference is that if an object file contained in a library is not
|
|
referenced anywhere in the program, then it is not linked in.
|
|
<P>
|
|
Arguments ending in .c are passed to the C compiler, which generates
|
|
a .o object file. This object file is linked with the program.
|
|
<P>
|
|
Arguments ending in .o or .a are assumed to be C object files and
|
|
libraries. They are linked with the program.
|
|
<P>
|
|
The output of the linking phase is a regular Unix executable file. It
|
|
does not need
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlrun">ocamlrun</A></B>(1)
|
|
|
|
to run.
|
|
<P>
|
|
<B>ocamlopt.opt</B>
|
|
|
|
is the same compiler as
|
|
<B>ocamlopt</B>,
|
|
|
|
but compiled with itself instead of with the bytecode compiler
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1).
|
|
|
|
Thus, it behaves exactly like
|
|
<B>ocamlopt</B>,
|
|
|
|
but compiles faster.
|
|
<B>ocamlopt.opt</B>
|
|
|
|
is not available in all installations of OCaml.
|
|
<P>
|
|
<A NAME="lbAE"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<P>
|
|
The following command-line options are recognized by
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1).
|
|
|
|
<DL COMPACT>
|
|
<DT id="1"><B>-a</B>
|
|
|
|
<DD>
|
|
Build a library (.cmxa/.a file) with the object files (.cmx/.o
|
|
files) given on the command line, instead of linking them into an
|
|
executable file. The name of the library must be set with the
|
|
<B>-o</B>
|
|
|
|
option.
|
|
<P>
|
|
If
|
|
<B>-cclib</B> or<B> -ccopt</B>
|
|
|
|
options are passed on the command
|
|
line, these options are stored in the resulting .cmxa library. Then,
|
|
linking with this library automatically adds back the
|
|
<B>-cclib</B> and<B> -ccopt</B>
|
|
|
|
options as if they had been provided on the
|
|
command line, unless the
|
|
<B>-noautolink</B>
|
|
|
|
option is given. Additionally, a substring
|
|
<B>$CAMLORIGIN</B>
|
|
|
|
inside a
|
|
<B> -ccopt</B>
|
|
|
|
options will be replaced by the full path to the .cma library,
|
|
excluding the filename.
|
|
<DT id="2"><B>-absname</B>
|
|
|
|
<DD>
|
|
Show absolute filenames in error messages.
|
|
<DT id="3"><B>-annot</B>
|
|
|
|
<DD>
|
|
Dump detailed information about the compilation (types, bindings,
|
|
tail-calls, etc). The information for file
|
|
<I>src</I>.ml
|
|
|
|
is put into file
|
|
<I>src</I>.annot.
|
|
|
|
In case of a type error, dump all the information inferred by the
|
|
type-checker before the error. The
|
|
<I>src</I>.annot
|
|
|
|
file can be used with the emacs commands given in
|
|
<B>emacs/caml-types.el</B>
|
|
|
|
to display types and other annotations interactively.
|
|
<DT id="4"><B>-bin-annot</B>
|
|
|
|
<DD>
|
|
Dump detailed information about the compilation (types, bindings,
|
|
tail-calls, etc) in binary format. The information for file
|
|
<I>src</I>.ml
|
|
|
|
is put into file
|
|
<I>src</I>.cmt.
|
|
|
|
In case of a type error, dump
|
|
all the information inferred by the type-checker before the error.
|
|
The annotation files produced by
|
|
<B>-bin-annot</B>
|
|
|
|
contain more information
|
|
and are much more compact than the files produced by
|
|
<B>-annot</B>.
|
|
|
|
<DT id="5"><B>-c</B>
|
|
|
|
<DD>
|
|
Compile only. Suppress the linking phase of the
|
|
compilation. Source code files are turned into compiled files, but no
|
|
executable file is produced. This option is useful to
|
|
compile modules separately.
|
|
<DT id="6"><B>-cc</B><I> ccomp</I>
|
|
|
|
<DD>
|
|
Use
|
|
<I>ccomp</I>
|
|
|
|
as the C linker called to build the final executable and as the C
|
|
compiler for compiling .c source files.
|
|
<DT id="7"><B>-cclib -l</B><I>libname</I>
|
|
|
|
<DD>
|
|
Pass the
|
|
<B>-l</B><I>libname</I>
|
|
|
|
option to the linker. This causes the given C library to be linked
|
|
with the program.
|
|
<DT id="8"><B>-ccopt</B><I> option</I>
|
|
|
|
<DD>
|
|
Pass the given option to the C compiler and linker. For instance,
|
|
<B>-ccopt -L</B><I>dir</I>
|
|
|
|
causes the C linker to search for C libraries in
|
|
directory
|
|
<I>dir</I>.
|
|
|
|
<DT id="9"><B>-color</B><I> mode</I>
|
|
|
|
<DD>
|
|
Enable or disable colors in compiler messages (especially warnings and errors).
|
|
The following modes are supported:
|
|
<P>
|
|
<B>auto</B>
|
|
|
|
use heuristics to enable colors only if the output supports them (an
|
|
ANSI-compatible tty terminal);
|
|
<P>
|
|
<B>always</B>
|
|
|
|
enable colors unconditionally;
|
|
<P>
|
|
<B>never</B>
|
|
|
|
disable color output.
|
|
<P>
|
|
The default setting is
|
|
<B>auto,</B>
|
|
|
|
and the current heuristic
|
|
checks that the "TERM" environment variable exists and is
|
|
not empty or "dumb", and that isatty(stderr) holds.
|
|
<P>
|
|
The environment variable "OCAML_COLOR" is considered if -color is not
|
|
provided. Its values are auto/always/never as above.
|
|
<P>
|
|
<DT id="10"><B>-error-style</B><I> mode</I>
|
|
|
|
<DD>
|
|
Control the way error messages and warnings are printed.
|
|
The following modes are supported:
|
|
<P>
|
|
<B>short</B>
|
|
|
|
only print the error and its location;
|
|
<P>
|
|
<B>contextual</B>
|
|
|
|
like "short", but also display the source code snippet corresponding
|
|
to the location of the error.
|
|
<P>
|
|
The default setting is
|
|
<B>contextual.</B>
|
|
|
|
<P>
|
|
The environment variable "OCAML_ERROR_STYLE" is considered if
|
|
-error-style is not provided. Its values are short/contextual as
|
|
above.
|
|
<P>
|
|
<DT id="11"><B>-compact</B>
|
|
|
|
<DD>
|
|
Optimize the produced code for space rather than for time. This
|
|
results in smaller but slightly slower programs. The default is to
|
|
optimize for speed.
|
|
<DT id="12"><B>-config</B>
|
|
|
|
<DD>
|
|
Print the version number of
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlopt">ocamlopt</A></B>(1)
|
|
|
|
and a detailed summary of its configuration, then exit.
|
|
<DT id="13"><B>-config-var</B>
|
|
|
|
<DD>
|
|
Print the value of a specific configuration variable
|
|
from the
|
|
<B>-config</B>
|
|
|
|
output, then exit. If the variable does not exist,
|
|
the exit code is non-zero.
|
|
<DT id="14"><B>-depend ocamldep-args</B>
|
|
|
|
<DD>
|
|
Compute dependencies, as ocamldep would do.
|
|
<DT id="15"><B>-for-pack</B><I> module-path</I>
|
|
|
|
<DD>
|
|
Generate an object file (.cmx and .o files) that can later be included
|
|
as a sub-module (with the given access path) of a compilation unit
|
|
constructed with
|
|
<B>-pack</B>.
|
|
|
|
For instance,
|
|
<B>ocamlopt -for-pack P -c A.ml</B>
|
|
|
|
will generate a.cmx and a.o files that can later be used with
|
|
<B>ocamlopt -pack -o P.cmx a.cmx</B>.
|
|
|
|
<DT id="16"><B>-g</B>
|
|
|
|
<DD>
|
|
Add debugging information while compiling and linking. This option is
|
|
required in order to produce stack backtraces when
|
|
the program terminates on an uncaught exception (see
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlrun">ocamlrun</A></B>(1)).
|
|
|
|
<DT id="17"><B>-i</B>
|
|
|
|
<DD>
|
|
Cause the compiler to print all defined names (with their inferred
|
|
types or their definitions) when compiling an implementation (.ml
|
|
file). No compiled files (.cmo and .cmi files) are produced.
|
|
This can be useful to check the types inferred by the
|
|
compiler. Also, since the output follows the syntax of interfaces, it
|
|
can help in writing an explicit interface (.mli file) for a file:
|
|
just redirect the standard output of the compiler to a .mli file,
|
|
and edit that file to remove all declarations of unexported names.
|
|
<DT id="18"><B>-I</B><I> directory</I>
|
|
|
|
<DD>
|
|
Add the given directory to the list of directories searched for
|
|
compiled interface files (.cmi), compiled object code files (.cmx),
|
|
and libraries (.cmxa). By default, the current directory is searched
|
|
first, then the standard library directory. Directories added with -I
|
|
are searched after the current directory, in the order in which they
|
|
were given on the command line, but before the standard library
|
|
directory. See also option
|
|
<B>-nostdlib</B>.
|
|
|
|
<P>
|
|
If the given directory starts with
|
|
<B>+</B>,
|
|
|
|
it is taken relative to the
|
|
standard library directory. For instance,
|
|
<B>-I +compiler-libs</B>
|
|
|
|
adds the subdirectory
|
|
<B>compiler-libs</B>
|
|
|
|
of the standard library to the search path.
|
|
<DT id="19"><B>-impl</B><I> filename</I>
|
|
|
|
<DD>
|
|
Compile the file
|
|
<I>filename</I>
|
|
|
|
as an implementation file, even if its extension is not .ml.
|
|
<DT id="20"><B>-inline</B><I> n</I>
|
|
|
|
<DD>
|
|
Set aggressiveness of inlining to
|
|
<I>n</I>,
|
|
|
|
where
|
|
<I>n</I>
|
|
|
|
is a positive
|
|
integer. Specifying
|
|
<B>-inline 0</B>
|
|
|
|
prevents all functions from being
|
|
inlined, except those whose body is smaller than the call site. Thus,
|
|
inlining causes no expansion in code size. The default aggressiveness,
|
|
<B>-inline 1</B>,
|
|
|
|
allows slightly larger functions to be inlined, resulting
|
|
in a slight expansion in code size. Higher values for the
|
|
<B>-inline</B>
|
|
|
|
option cause larger and larger functions to become candidate for
|
|
inlining, but can result in a serious increase in code size.
|
|
<DT id="21"><B>-intf</B><I> filename</I>
|
|
|
|
<DD>
|
|
Compile the file
|
|
<I>filename</I>
|
|
|
|
as an interface file, even if its extension is not .mli.
|
|
<DT id="22"><B>-intf-suffix</B><I> string</I>
|
|
|
|
<DD>
|
|
Recognize file names ending with
|
|
<I>string</I>
|
|
|
|
as interface files (instead of the default .mli).
|
|
<DT id="23"><B>-keep-docs</B>
|
|
|
|
<DD>
|
|
Keep documentation strings in generated .cmi files.
|
|
<DT id="24"><B>-keep-locs</B>
|
|
|
|
<DD>
|
|
Keep locations in generated .cmi files.
|
|
<DT id="25"><B>-labels</B>
|
|
|
|
<DD>
|
|
Labels are not ignored in types, labels may be used in applications,
|
|
and labelled parameters can be given in any order. This is the default.
|
|
<DT id="26"><B>-linkall</B>
|
|
|
|
<DD>
|
|
Force all modules contained in libraries to be linked in. If this
|
|
flag is not given, unreferenced modules are not linked in. When
|
|
building a library
|
|
(<B>-a</B>
|
|
|
|
flag), setting the
|
|
<B>-linkall</B>
|
|
|
|
flag forces all
|
|
subsequent links of programs involving that library to link all the
|
|
modules contained in the library.
|
|
When compiling a module (option
|
|
<B>-c</B>),
|
|
|
|
setting the
|
|
<B>-linkall</B>
|
|
|
|
option ensures that this module will
|
|
always be linked if it is put in a library and this library is linked.
|
|
<DT id="27"><B>-linscan</B>
|
|
|
|
<DD>
|
|
Use linear scan register allocation. Compiling with this allocator is faster
|
|
than with the usual graph coloring allocator, sometimes quite drastically so for
|
|
long functions and modules. On the other hand, the generated code can be a bit
|
|
slower.
|
|
<DT id="28"><B>-match-context-rows</B>
|
|
|
|
<DD>
|
|
Set number of rows of context used during pattern matching
|
|
compilation. Lower values cause faster compilation, but
|
|
less optimized code. The default value is 32.
|
|
<DT id="29"><B>-no-alias-deps</B>
|
|
|
|
<DD>
|
|
Do not record dependencies for module aliases.
|
|
<DT id="30"><B>-no-app-funct</B>
|
|
|
|
<DD>
|
|
Deactivates the applicative behaviour of functors. With this option,
|
|
each functor application generates new types in its result and
|
|
applying the same functor twice to the same argument yields two
|
|
incompatible structures.
|
|
<DT id="31"><B>-noassert</B>
|
|
|
|
<DD>
|
|
Do not compile assertion checks. Note that the special form
|
|
<B>assert false</B>
|
|
|
|
is always compiled because it is typed specially.
|
|
This flag has no effect when linking already-compiled files.
|
|
<DT id="32"><B>-noautolink</B>
|
|
|
|
<DD>
|
|
When linking .cmxa libraries, ignore
|
|
<B>-cclib</B> and<B> -ccopt</B>
|
|
|
|
options potentially contained in the libraries (if these options were
|
|
given when building the libraries). This can be useful if a library
|
|
contains incorrect specifications of C libraries or C options; in this
|
|
case, during linking, set
|
|
<B>-noautolink</B>
|
|
|
|
and pass the correct C libraries and options on the command line.
|
|
<DT id="33"><B>-nodynlink</B>
|
|
|
|
<DD>
|
|
Allow the compiler to use some optimizations that are valid only for code
|
|
that is never dynlinked.
|
|
<DT id="34"><B>-nostdlib</B>
|
|
|
|
<DD>
|
|
Do not automatically add the standard library directory to the list of
|
|
directories searched for compiled interface files (.cmi), compiled
|
|
object code files (.cmx), and libraries (.cmxa). See also option
|
|
<B>-I</B>.
|
|
|
|
<DT id="35"><B>-nolabels</B>
|
|
|
|
<DD>
|
|
Ignore non-optional labels in types. Labels cannot be used in
|
|
applications, and parameter order becomes strict.
|
|
<DT id="36"><B>-o</B><I> exec-file</I>
|
|
|
|
<DD>
|
|
Specify the name of the output file produced by the linker. The
|
|
default output name is a.out, in keeping with the Unix tradition. If the
|
|
<B>-a</B>
|
|
|
|
option is given, specify the name of the library produced. If the
|
|
<B>-pack</B>
|
|
|
|
option is given, specify the name of the packed object file produced.
|
|
If the
|
|
<B>-output-obj</B>
|
|
|
|
option is given, specify the name of the output file produced. If the
|
|
<B>-shared</B>
|
|
|
|
option is given, specify the name of plugin file produced.
|
|
This can also be used when compiling an interface or implementation
|
|
file, without linking, in which case it sets the name of the cmi or
|
|
cmo file, and also sets the module name to the file name up to the
|
|
first dot.
|
|
<DT id="37"><B>-opaque</B>
|
|
|
|
<DD>
|
|
When compiling a .mli interface file, this has the same effect as the
|
|
<B>-opaque</B>
|
|
|
|
option of the bytecode compiler. When compiling a .ml implementation
|
|
file, this produces a .cmx file without cross-module optimization
|
|
information, which reduces recompilation on module change.
|
|
<DT id="38"><B>-open</B><I> module</I>
|
|
|
|
<DD>
|
|
Opens the given module before processing the interface or
|
|
implementation files. If several
|
|
<B>-open</B>
|
|
|
|
options are given, they are processed in order, just as if
|
|
the statements open! module1;; ... open! moduleN;; were added
|
|
at the top of each file.
|
|
<DT id="39"><B>-output-obj</B>
|
|
|
|
<DD>
|
|
Cause the linker to produce a C object file instead of an executable
|
|
file. This is useful to wrap OCaml code as a C library,
|
|
callable from any C program. The name of the output object file
|
|
must be set with the
|
|
<B>-o</B>
|
|
|
|
option.
|
|
This option can also be used to produce a compiled shared/dynamic
|
|
library (.so extension).
|
|
<DT id="40"><B>-p</B>
|
|
|
|
<DD>
|
|
Generate extra code to write profile information when the program is
|
|
executed. The profile information can then be examined with the
|
|
analysis program
|
|
<B><A HREF="/cgi-bin/man/man2html?1+gprof">gprof</A></B>(1).
|
|
|
|
The
|
|
<B>-p</B>
|
|
|
|
option must be given both at
|
|
compile-time and at link-time. Linking object files not compiled with
|
|
<B>-p</B>
|
|
|
|
is possible, but results in less precise profiling.
|
|
<P>
|
|
See the
|
|
<B><A HREF="/cgi-bin/man/man2html?1+gprof">gprof</A></B>(1)
|
|
|
|
man page for more information about the profiles.
|
|
<P>
|
|
Full support for
|
|
<B><A HREF="/cgi-bin/man/man2html?1+gprof">gprof</A></B>(1)
|
|
|
|
is only available for certain platforms
|
|
(currently: Intel x86/Linux and Alpha/Digital Unix).
|
|
On other platforms, the
|
|
<B>-p</B>
|
|
|
|
option will result in a less precise
|
|
profile (no call graph information, only a time profile).
|
|
<DT id="41"><B>-pack</B>
|
|
|
|
<DD>
|
|
Build an object file (.cmx and .o files) and its associated compiled
|
|
interface (.cmi) that combines the .cmx object
|
|
files given on the command line, making them appear as sub-modules of
|
|
the output .cmx file. The name of the output .cmx file must be
|
|
given with the
|
|
<B>-o</B>
|
|
|
|
option. For instance,
|
|
<B>ocamlopt -pack -o P.cmx A.cmx B.cmx C.cmx</B>
|
|
|
|
generates compiled files P.cmx, P.o and P.cmi describing a
|
|
compilation unit having three sub-modules A, B and C,
|
|
corresponding to the contents of the object files A.cmx, B.cmx and
|
|
C.cmx. These contents can be referenced as P.A, P.B and P.C
|
|
in the remainder of the program.
|
|
<P>
|
|
The .cmx object files being combined must have been compiled with
|
|
the appropriate
|
|
<B>-for-pack</B>
|
|
|
|
option. In the example above,
|
|
A.cmx, B.cmx and C.cmx must have been compiled with
|
|
<B>ocamlopt -for-pack P</B>.
|
|
|
|
<P>
|
|
Multiple levels of packing can be achieved by combining
|
|
<B>-pack</B>
|
|
|
|
with
|
|
<B>-for-pack</B>.
|
|
|
|
See
|
|
<I>The OCaml user's manual</I>,
|
|
|
|
chapter "Native-code compilation" for more details.
|
|
<DT id="42"><B>-plugin</B><I> plugin</I>
|
|
|
|
<DD>
|
|
Dynamically load the code of the given
|
|
<I>plugin</I>
|
|
|
|
(a .cmo, .cma or .cmxs file) in the compiler. The plugin must exist in
|
|
the same kind of code as the compiler (ocamlopt.byte must load bytecode
|
|
plugins, while ocamlopt.opt must load native code plugins), and
|
|
extension adaptation is done automatically for .cma files (to .cmxs files
|
|
if the compiler is compiled in native code).
|
|
<DT id="43"><B>-pp</B><I> command</I>
|
|
|
|
<DD>
|
|
Cause the compiler to call the given
|
|
<I>command</I>
|
|
|
|
as a preprocessor for each source file. The output of
|
|
<I>command</I>
|
|
|
|
is redirected to
|
|
an intermediate file, which is compiled. If there are no compilation
|
|
errors, the intermediate file is deleted afterwards.
|
|
<DT id="44"><B>-ppx</B><I> command</I>
|
|
|
|
<DD>
|
|
After parsing, pipe the abstract syntax tree through the preprocessor
|
|
<I>command</I>.
|
|
|
|
The module
|
|
<B><A HREF="/cgi-bin/man/man2html?3+Ast_mapper">Ast_mapper</A></B>(3)
|
|
|
|
implements the external interface of a preprocessor.
|
|
<DT id="45"><B>-principal</B>
|
|
|
|
<DD>
|
|
Check information path during type-checking, to make sure that all
|
|
types are derived in a principal way. All programs accepted in
|
|
<B>-principal</B>
|
|
|
|
mode are also accepted in default mode with equivalent
|
|
types, but different binary signatures.
|
|
<DT id="46"><B>-rectypes</B>
|
|
|
|
<DD>
|
|
Allow arbitrary recursive types during type-checking. By default,
|
|
only recursive types where the recursion goes through an object type
|
|
are supported. Note that once you have created an interface using this
|
|
flag, you must use it again for all dependencies.
|
|
<DT id="47"><B>-runtime-variant</B><I> suffix</I>
|
|
|
|
<DD>
|
|
Add
|
|
<I>suffix</I>
|
|
|
|
to the name of the runtime library that will be used by the program.
|
|
If OCaml was configured with option
|
|
<B>-with-debug-runtime</B>,
|
|
|
|
then the
|
|
<B>d</B>
|
|
|
|
suffix is supported and gives a debug version of the runtime.
|
|
<DT id="48"><B>-S</B>
|
|
|
|
<DD>
|
|
Keep the assembly code produced during the compilation. The assembly
|
|
code for the source file
|
|
<I>x</I>.ml
|
|
|
|
is saved in the file
|
|
<I>x</I>.s.
|
|
|
|
<DT id="49"><B>-stop-after</B><I> pass</I>
|
|
|
|
<DD>
|
|
Stop compilation after the given compilation pass. The currently
|
|
supported passes are:
|
|
<B>parsing</B>,
|
|
|
|
<B>typing</B>.
|
|
|
|
<DT id="50"><B>-safe-string</B>
|
|
|
|
<DD>
|
|
Enforce the separation between types
|
|
<B>string</B> and <B>bytes</B>,
|
|
|
|
thereby making strings read-only. This is the default.
|
|
<DT id="51"><B>-shared</B>
|
|
|
|
<DD>
|
|
Build a plugin (usually .cmxs) that can be dynamically loaded with
|
|
the
|
|
<B>Dynlink</B>
|
|
|
|
module. The name of the plugin must be
|
|
set with the
|
|
<B>-o</B>
|
|
|
|
option. A plugin can include a number of OCaml
|
|
modules and libraries, and extra native objects (.o, .a files).
|
|
Building native plugins is only supported for some
|
|
operating system. Under some systems (currently,
|
|
only Linux AMD 64), all the OCaml code linked in a plugin must have
|
|
been compiled without the
|
|
<B>-nodynlink</B>
|
|
|
|
flag. Some constraints might also
|
|
apply to the way the extra native objects have been compiled (under
|
|
Linux AMD 64, they must contain only position-independent code).
|
|
<DT id="52"><B>-short-paths</B>
|
|
|
|
<DD>
|
|
When a type is visible under several module-paths, use the shortest
|
|
one when printing the type's name in inferred interfaces and error and
|
|
warning messages.
|
|
<DT id="53"><B>-strict-sequence</B>
|
|
|
|
<DD>
|
|
The left-hand part of a sequence must have type unit.
|
|
<DT id="54"><B>-unboxed-types</B>
|
|
|
|
<DD>
|
|
When a type is unboxable (i.e. a record with a single argument or a
|
|
concrete datatype with a single constructor of one argument) it will
|
|
be unboxed unless annotated with
|
|
<B>[@@ocaml.boxed]</B>.
|
|
|
|
<DT id="55"><B>-no-unboxed-types</B>
|
|
|
|
<DD>
|
|
When a type is unboxable it will be boxed unless annotated with
|
|
<B>[@@ocaml.unboxed]</B>.
|
|
|
|
This is the default.
|
|
<DT id="56"><B>-unsafe</B>
|
|
|
|
<DD>
|
|
Turn bound checking off for array and string accesses (the
|
|
<B>v.(i)</B>and<B>s.[i]</B>
|
|
|
|
constructs). Programs compiled with
|
|
<B>-unsafe</B>
|
|
|
|
are therefore
|
|
faster, but unsafe: anything can happen if the program accesses an
|
|
array or string outside of its bounds. Additionally, turn off the
|
|
check for zero divisor in integer division and modulus operations.
|
|
With
|
|
<B>-unsafe</B>,
|
|
|
|
an integer division (or modulus) by zero can halt the
|
|
program or continue with an unspecified result instead of raising a
|
|
<B>Division_by_zero</B>
|
|
|
|
exception.
|
|
<DT id="57"><B>-unsafe-string</B>
|
|
|
|
<DD>
|
|
Identify the types
|
|
<B>string</B> and <B>bytes</B>,
|
|
|
|
thereby making strings writable.
|
|
This is intended for compatibility with old source code and should not
|
|
be used with new software.
|
|
<DT id="58"><B>-v</B>
|
|
|
|
<DD>
|
|
Print the version number of the compiler and the location of the
|
|
standard library directory, then exit.
|
|
<DT id="59"><B>-verbose</B>
|
|
|
|
<DD>
|
|
Print all external commands before they are executed, in particular
|
|
invocations of the assembler, C compiler, and linker.
|
|
<DT id="60"><B>-version</B> or <B>-vnum</B>
|
|
|
|
<DD>
|
|
Print the version number of the compiler in short form (e.g. "3.11.0"),
|
|
then exit.
|
|
<DT id="61"><B>-w</B><I> warning-list</I>
|
|
|
|
<DD>
|
|
Enable, disable, or mark as fatal the warnings specified by the argument
|
|
<I>warning-list</I>.
|
|
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1)
|
|
|
|
for the syntax of
|
|
<I>warning-list</I>.
|
|
|
|
<DT id="62"><B>-warn-error</B><I> warning-list</I>
|
|
|
|
<DD>
|
|
Mark as fatal the warnings specified in the argument
|
|
<I>warning-list</I>.
|
|
|
|
The compiler will stop with an error when one of these
|
|
warnings is emitted. The
|
|
<I>warning-list</I>
|
|
|
|
has the same meaning as for
|
|
the
|
|
<B>-w</B>
|
|
|
|
option: a
|
|
<B>+</B>
|
|
|
|
sign (or an uppercase letter) marks the corresponding warnings as fatal, a
|
|
<B>-</B>
|
|
|
|
sign (or a lowercase letter) turns them back into non-fatal warnings, and a
|
|
<B>@</B>
|
|
|
|
sign both enables and marks as fatal the corresponding warnings.
|
|
<P>
|
|
Note: it is not recommended to use the
|
|
<B>-warn-error</B>
|
|
|
|
option in production code, because it will almost certainly prevent
|
|
compiling your program with later versions of OCaml when they add new
|
|
warnings or modify existing warnings.
|
|
<P>
|
|
The default setting is
|
|
<B>-warn-error -a+31</B>
|
|
|
|
(only warning 31 is fatal).
|
|
<DT id="63"><B>-warn-help</B>
|
|
|
|
<DD>
|
|
Show the description of all available warning numbers.
|
|
<DT id="64"><B>-where</B>
|
|
|
|
<DD>
|
|
Print the location of the standard library, then exit.
|
|
<DT id="65"><B>-</B><I> file</I>
|
|
|
|
<DD>
|
|
Process
|
|
<I>file</I>
|
|
|
|
as a file name, even if it starts with a dash (-) character.
|
|
<DT id="66"><B>-help</B> or<B> --help</B>
|
|
|
|
<DD>
|
|
Display a short usage summary and exit.
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>OPTIONS FOR THE IA32 ARCHITECTURE</H2>
|
|
|
|
<P>
|
|
The IA32 code generator (Intel Pentium, AMD Athlon) supports the
|
|
following additional option:
|
|
<DL COMPACT>
|
|
<DT id="67"><B>-ffast-math</B>
|
|
|
|
<DD>
|
|
Use the IA32 instructions to compute
|
|
trigonometric and exponential functions, instead of calling the
|
|
corresponding library routines. The functions affected are:
|
|
<B>atan</B>,
|
|
|
|
<B>atan2</B>,
|
|
|
|
<B>cos</B>,
|
|
|
|
<B>log</B>,
|
|
|
|
<B>log10</B>,
|
|
|
|
<B>sin</B>,
|
|
|
|
<B>sqrt</B>
|
|
|
|
and
|
|
<B>tan</B>.
|
|
|
|
The resulting code runs faster, but the range of supported arguments
|
|
and the precision of the result can be reduced. In particular,
|
|
trigonometric operations
|
|
<B>cos</B>,
|
|
|
|
<B>sin</B>,
|
|
|
|
<B>tan</B>
|
|
|
|
have their range reduced to [-2^64, 2^64].
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H2>OPTIONS FOR THE AMD64 ARCHITECTURE</H2>
|
|
|
|
<P>
|
|
The AMD64 code generator (64-bit versions of Intel Pentium and AMD
|
|
Athlon) supports the following additional options:
|
|
<DL COMPACT>
|
|
<DT id="68"><B>-fPIC</B>
|
|
|
|
<DD>
|
|
Generate position-independent machine code. This is the default.
|
|
<DT id="69"><B>-fno-PIC</B>
|
|
|
|
<DD>
|
|
Generate position-dependent machine code.
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAH"> </A>
|
|
<H2>OPTIONS FOR THE ARM ARCHITECTURE</H2>
|
|
|
|
The ARM code generator supports the following additional options:
|
|
<DL COMPACT>
|
|
<DT id="70"><B>-farch=armv4|armv5|armv5te|armv6|armv6t2|armv7</B>
|
|
|
|
<DD>
|
|
Select the ARM target architecture
|
|
<DT id="71"><B>-ffpu=soft|vfpv2|vfpv3-d16|vfpv3</B>
|
|
|
|
<DD>
|
|
Select the floating-point hardware
|
|
<DT id="72"><B>-fPIC</B>
|
|
|
|
<DD>
|
|
Generate position-independent machine code.
|
|
<DT id="73"><B>-fno-PIC</B>
|
|
|
|
<DD>
|
|
Generate position-dependent machine code. This is the default.
|
|
<DT id="74"><B>-fthumb</B>
|
|
|
|
<DD>
|
|
Enable Thumb/Thumb-2 code generation
|
|
<DT id="75"><B>-fno-thumb</B>
|
|
|
|
<DD>
|
|
Disable Thumb/Thumb-2 code generation
|
|
</DL>
|
|
<P>
|
|
|
|
The default values for target architecture, floating-point hardware
|
|
and thumb usage were selected at configure-time when building
|
|
<B>ocamlopt</B>
|
|
|
|
itself. This configuration can be inspected using
|
|
<B>ocamlopt -config</B>.
|
|
|
|
Target architecture depends on the "model" setting, while
|
|
floating-point hardware and thumb support are determined from the ABI
|
|
setting in "system" (
|
|
<B>linux_eabi</B>or<B>linux_eabihf</B>).
|
|
|
|
<P>
|
|
<A NAME="lbAI"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?1+ocamlc">ocamlc</A></B>(1).
|
|
|
|
<BR>
|
|
|
|
<I>The OCaml user's manual</I>,
|
|
|
|
chapter "Native-code compilation".
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="76"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="77"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="78"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="79"><A HREF="#lbAE">OPTIONS</A><DD>
|
|
<DT id="80"><A HREF="#lbAF">OPTIONS FOR THE IA32 ARCHITECTURE</A><DD>
|
|
<DT id="81"><A HREF="#lbAG">OPTIONS FOR THE AMD64 ARCHITECTURE</A><DD>
|
|
<DT id="82"><A HREF="#lbAH">OPTIONS FOR THE ARM ARCHITECTURE</A><DD>
|
|
<DT id="83"><A HREF="#lbAI">SEE ALSO</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:05:20 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|