Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
OCAMLC(1)		    General Commands Manual		     OCAMLC(1)

       ocamlc -	The OCaml bytecode compiler

       ocamlc [	options	] filename ...

       ocamlc.opt [ options ] filename ...

       The  OCaml  bytecode  compiler ocamlc(1)	compiles OCaml source files to
       bytecode	object files and links these object files  to  produce	stand-
       alone  bytecode	executable files.  These executable files are then run
       by the bytecode interpreter ocamlrun(1).

       The ocamlc(1) command has a command-line	interface similar to  the  one
       of  most	 C  compilers.	It accepts several types of arguments and pro-
       cesses them sequentially, after all options have	been processed:

       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 x.mli, the
       ocamlc(1) compiler produces a compiled interface	in the file x.cmi.

       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, the ocamlc(1) compiler pro-
       duces compiled object bytecode in the file x.cmo.

       If the interface	file x.mli exists, the implementation is  checked
       against the corresponding compiled interface x.cmi, which is assumed to
       exist. If no interface x.mli is provided, the compilation of  pro-
       duces  a	 compiled interface file x.cmi in addition to the compiled ob-
       ject code file x.cmo.  The file x.cmi produced corresponds to an	inter-
       face  that  exports  everything	that  is defined in the	implementation

       Arguments ending	in .cmo	are taken  to  be  compiled  object  bytecode.
       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 standalone executable program.	The order in which .cmo
       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	 x.cmo	file must come before all .cmo files that refer	to the
       unit x.

       Arguments ending	in .cma	are taken to be	libraries of object  bytecode.
       A  library  of  object  bytecode	packs in a single file a set of	object
       bytecode	files (.cmo files). Libraries are built	 with  ocamlc -a  (see
       the  description	of the -a option below). The object files contained in
       the library are linked as regular .cmo files (see above), in the	 order
       specified  when the .cma	file 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.

       Arguments  ending in .c are passed to the C compiler, which generates a
       .o object file. This object file	is linked  with	 the  program  if  the
       -custom flag is set (see	the description	of -custom below).

       Arguments  ending  in .o	or .a are assumed to be	C object files and li-
       braries.	They are passed	to the C linker	when linking in	 -custom  mode
       (see the	description of -custom below).

       Arguments  ending  in  .so are assumed to be C shared libraries (DLLs).
       During linking, they are	searched for external C	 functions  referenced
       from the	OCaml code, and	their names are	written	in the generated byte-
       code executable.	 The run-time system ocamlrun(1) then loads  them  dy-
       namically at program start-up time.

       The  output of the linking phase	is a file containing compiled bytecode
       that can	be executed by the OCaml  bytecode  interpreter:  the  command
       ocamlrun(1).  If	caml.out is the	name of	the file produced by the link-
       ing phase, the command ocamlrun caml.out	 arg1  arg2 ...	argn  executes
       the  compiled  code  contained in caml.out, passing it as arguments the
       character strings arg1 to argn.	(See ocamlrun(1) for more details.)

       On most systems,	the file produced by the linking phase can be run  di-
       rectly,	as  in:	./caml.out arg1	 arg2 ... argn.	 The produced file has
       the executable bit set, and it manages to launch	 the  bytecode	inter-
       preter by itself.

       ocamlc.opt  is  the  same compiler as ocamlc, but compiled with the na-
       tive-code compiler ocamlopt(1).	Thus, it behaves exactly like  ocamlc,
       but  compiles faster.  ocamlc.opt may not be available in all installa-
       tions of	OCaml.

       The following command-line options are recognized by ocamlc(1).

       -a     Build a library (.cma file) with the object files	 (.cmo	files)
	      given  on	the command line, instead of linking them into an exe-
	      cutable file. The	name of	the library must be set	 with  the  -o

	      If  -custom, -cclib or -ccopt  options are passed	on the command
	      line, these options are stored in	the  resulting	.cma  library.
	      Then,  linking  with  this  library  automatically adds back the
	      -custom, -cclib and -ccopt options as if they had	been  provided
	      on the command line, unless the -noautolink option is given. Ad-
	      ditionally, a substring $CAMLORIGIN  inside  a   -ccopt  options
	      will be replaced by the full path	to the .cma library, excluding
	      the filename.  -absname Show absolute filenames  in  error  mes-

       -annot Dump  detailed  information  about the compilation (types, bind-
	      ings, tail-calls,	etc).  The information for file is  put
	      into  file src.annot.  In	case of	a type error, dump all the in-
	      formation	inferred by the	type-checker  before  the  error.  The
	      src.annot	 file  can  be	used  with the emacs commands given in
	      emacs/caml-types.el to display types and other  annotations  in-

	      Dump  detailed  information  about the compilation (types, bind-
	      ings, tail-calls,	etc) in	binary	format.	 The  information  for
	      file is put into file src.cmt.  In case of a type	error,
	      dump all the information inferred	by the type-checker before the
	      error.  The annotation files produced by -bin-annot contain more
	      information and are much more compact than the files produced by

       -c     Compile  only.  Suppress	the  linking phase of the compilation.
	      Source code files	are turned into	compiled files,	 but  no  exe-
	      cutable  file is produced. This option is	useful to compile mod-
	      ules separately.

       -cc ccomp
	      Use ccomp	as the C linker	when linking in	"custom	runtime"  mode
	      (see  the	-custom	option)	and as the C compiler for compiling .c
	      source files.

       -cclib -llibname
	      Pass the -llibname option	to the C linker	when linking in	 "cus-
	      tom  runtime"  mode  (see	 the  -custom option). This causes the
	      given C library to be linked with	the program.

       -ccopt option
	      Pass the given option to the C compiler and linker, when linking
	      in "custom runtime" mode (see the	-custom	option). For instance,
	      -ccopt -Ldir causes the C	linker to search for  C	 libraries  in
	      directory	dir.

       -color mode
	      Enable  or disable colors	in compiler messages (especially warn-
	      ings and errors).	 The following modes are supported:

	      auto use heuristics to enable colors only	if the output supports
	      them (an ANSI-compatible tty terminal);

	      always enable colors unconditionally;

	      never disable color output.

	      The  default  setting  is	auto, and the current heuristic	checks
	      that the "TERM" environment variable exists and is not empty  or
	      "dumb", and that isatty(stderr) holds.

	      The  environment	variable "OCAML_COLOR" is considered if	-color
	      is not provided. Its values are auto/always/never	as above.

	      Check that the generated bytecode	executable can run  on	32-bit
	      platforms	 and signal an error if	it cannot. This	is useful when
	      compiling	bytecode on a 64-bit machine.

	      Print the	version	number of ocamlc(1) and	a detailed summary  of
	      its configuration, then exit.

	      Link  in "custom runtime"	mode. In the default linking mode, the
	      linker produces bytecode that is intended	to  be	executed  with
	      the  shared  runtime system, ocamlrun(1).	 In the	custom runtime
	      mode, the	linker produces	an output file that contains both  the
	      runtime  system  and the bytecode	for the	program. The resulting
	      file is larger, but it can be executed  directly,	 even  if  the
	      ocamlrun(1) command is not installed. Moreover, the "custom run-
	      time" mode enables linking OCaml code with user-defined C	 func-

	      Never  use  the  strip(1)	 command  on  executables  produced by
	      ocamlc -custom, this would remove	the bytecode part of the  exe-

	      Security warning:	never set the "setuid" or "setgid" bits	on ex-
	      ecutables	produced by ocamlc -custom, this would make them  vul-
	      nerable to attacks.

       -dllib -llibname
	      Arrange  for the C shared	library to be loaded dy-
	      namically	by the run-time	system ocamlrun(1) at program start-up

       -dllpath	dir
	      Adds  the	directory dir to the run-time search path for shared C
	      libraries.  At link-time,	shared libraries are searched  in  the
	      standard	search	path (the one corresponding to the -I option).
	      The -dllpath option simply stores	dir in the produced executable
	      file, where ocamlrun(1) can find it and use it.

       -for-pack module-path
	      Generate	an  object file	(.cmo file) that can later be included
	      as a sub-module (with the	given access path)  of	a  compilation
	      unit	constructed	with	 -pack.	     For     instance,
	      ocamlc -for-pack P -c will generate a.cmo that can later be
	      used with	ocamlc -pack -o	P.cmo a.cmo.  Note: you	can still pack
	      a	module that was	compiled without -for-pack but	in  this  case
	      exceptions will be printed with the wrong	names.

       -g     Add  debugging information while compiling and linking. This op-
	      tion is required in order	to be able to debug the	 program  with
	      ocamldebug(1)  and  to produce stack backtraces when the program
	      terminates on an uncaught	exception.

       -i     Cause the	compiler to print all defined names  (with  their  in-
	      ferred types or their definitions) when compiling	an implementa-
	      tion (.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	inter-
	      faces,  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.

       -I directory
	      Add the given directory to the list of directories searched  for
	      compiled	interface  files  (.cmi),  compiled  object code files
	      (.cmo),  libraries  (.cma),  and	C  libraries  specified	  with
	      -cclib -lxxx  .	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 -nostdlib.

	      If  the  given  directory	starts with +, it is taken relative to
	      the standard library directory. For instance,  -I	+compiler-libs
	      adds  the	 subdirectory compiler-libs of the standard library to
	      the search path.

       -impl filename
	      Compile the file filename	as an implementation file, even	if its
	      extension	is not .ml.

       -intf filename
	      Compile  the file	filename as an interface file, even if its ex-
	      tension is not .mli.

       -intf-suffix string
	      Recognize	file names ending with string as interface files  (in-
	      stead of the default .mli).

	      Keep documentation strings in generated .cmi files.

	      Keep locations in	generated .cmi files.

	      Labels  are not ignored in types,	labels may be used in applica-
	      tions, and labelled parameters can be given in any order.	  This
	      is the default.

	      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 (option -a), setting the -linkall	option
	      forces all subsequent links of programs involving	 that  library
	      to  link all the modules contained in the	library.  When compil-
	      ing a module (option -c),	setting	the  -linkall  option  ensures
	      that this	module will always be linked if	it is put in a library
	      and this library is linked.

	      Build a custom runtime system (in	the file specified  by	option
	      -o)  incorporating the C object files and	libraries given	on the
	      command line.  This custom runtime system	can be used  later  to
	      execute	bytecode   executables	 produced   with   the	option
	      ocamlc -use-runtime runtime-name.

	      Do not record dependencies for module aliases.

	      Deactivates the applicative behaviour of functors. With this op-
	      tion, each functor application generates new types in its	result
	      and applying the same functor twice to the same argument	yields
	      two incompatible structures.

	      Do not compile assertion checks.	Note that the special form as-
	      sert false is always compiled because  it	 is  typed  specially.
	      This flag	has no effect when linking already-compiled files.

	      When  linking  .cma libraries, ignore -custom, -cclib and	-ccopt
	      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 -noautolink and pass
	      the correct C libraries and options on the command line.

	      Ignore non-optional labels in types. Labels cannot  be  used  in
	      applications, and	parameter order	becomes	strict.

	      Do  not  automatically add the standard library directory	to the
	      list  of	directories  searched  for  compiled  interface	 files
	      (.cmi), compiled object code files (.cmo), libraries (.cma), and
	      C	libraries specified with -cclib	-lxxx .	 See also option -I.

       -o exec-file
	      Specify the name of the output file produced by the linker.  The
	      default  output  name  is	a.out, in keeping with the Unix	tradi-
	      tion. If the -a option is	given, specify the name	of the library
	      produced.	 If the	-pack option is	given, specify the name	of the
	      packed object file  produced.   If  the  -output-obj  option  is
	      given,  specify  the name	of the output 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.

	      Interface	 file  compiled	 with  this  option are	marked so that
	      other compilation	units depending	on it will not rely on any im-
	      plementation  details of the compiled implementation. The	native
	      compiler will not	access the .cmx	file of	this unit -- nor  warn
	      if it is absent. This can	improve	speed of compilation, for both
	      initial and incremental builds, at the expense of	performance of
	      the generated code.

       -open module
	      Opens the	given module before processing the interface or	imple-
	      mentation	files. If several -open	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.

	      Cause the	linker to produce a C object file instead of  a	 byte-
	      code  executable	file. This is useful to	wrap OCaml code	as a C
	      library, callable	from any C program. The	name of	the output ob-
	      ject  file  must be set with the -o option. This option can also
	      be used to produce a C source file (.c extension)	or a  compiled
	      shared/dynamic library (.so extension).

       -pack  Build a bytecode object file (.cmo file) and its associated com-
	      piled interface (.cmi) that combines the object files  given  on
	      the  command line, making	them appear as sub-modules of the out-
	      put .cmo file.  The name of the output .cmo file must  be	 given
	      with	 the	   -o	    option.	   For	     instance,
	      ocamlc -pack -o p.cmo a.cmo b.cmo	c.cmo generates	compiled files
	      p.cmo  and p.cmi describing a compilation	unit having three sub-
	      modules A, B and C, corresponding	to the contents	of the	object
	      files  a.cmo, b.cmo and c.cmo.  These contents can be referenced
	      as P.A, P.B and P.C in the remainder of the program.

       -plugin plugin
	      Dynamically load the code	of the given plugin (a .cmo,  .cma  or
	      .cmxs  file)  in the compiler. The plugin	must exist in the same
	      kind of code as the compiler  (ocamlc.byte  must	load  bytecode
	      plugins,	while  ocamlc.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).

       -pp command
	      Cause  the  compiler to call the given command as	a preprocessor
	      for each source file. The	output of command is redirected	to  an
	      intermediate  file,  which is compiled. If there are no compila-
	      tion errors, the intermediate file is  deleted  afterwards.  The
	      name  of this file is built from the basename of the source file
	      with the extension .ppi for an interface (.mli)  file  and  .ppo
	      for an implementation (.ml) file.

       -ppx command
	      After  parsing,  pipe  the abstract syntax tree through the pre-
	      processor	command.  The module Ast_mapper(3) implements the  ex-
	      ternal interface of a preprocessor.

	      Check  information  path during type-checking, to	make sure that
	      all types	are derived in a principal way.	 When  using  labelled
	      arguments	 and/or	 polymorphic methods, this flag	is required to
	      ensure future versions of	the compiler will  be  able  to	 infer
	      types  correctly,	 even if internal algorithms change.  All pro-
	      grams accepted in	-principal mode	are also accepted in  the  de-
	      fault  mode  with	 equivalent types, but different binary	signa-
	      tures, and this may slow down type checking; yet it  is  a  good
	      idea to use it once before publishing source code.

	      Allow  arbitrary	recursive  types during	type-checking.	By de-
	      fault, 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	depen-

       -runtime-variant	suffix
	      Add  suffix to the name of the runtime library that will be used
	      by the program.  If OCaml	was configured with  option  -with-de-
	      bug-runtime,  then  the  d suffix	is supported and gives a debug
	      version of the runtime.

	      Enforce the separation between types  string and bytes,  thereby
	      making  strings read-only. This will become the default in a fu-
	      ture version of OCaml.

	      When a type is  visible  under  several  module-paths,  use  the
	      shortest	one  when  printing the	type's name in inferred	inter-
	      faces and	error and warning messages.

	      Force the	left-hand part of each sequence	to have	type unit.

	      Compile or link multithreaded programs, in combination with  the
	      system "threads" library described in The	OCaml user's manual.

	      When  a  type is unboxable (i.e. a record	with a single argument
	      or a concrete datatype with a single constructor	of  one	 argu-
	      ment) it will be unboxed unless annotated	with [@@ocaml.boxed].

	      When a type is unboxable	it will	be boxed unless	annotated with
	      [@@ocaml.unboxed].  This is the default.

	      Turn bound checking off  for  array  and	string	accesses  (the
	      v.(i)ands.[i]  constructs).  Programs  compiled with -unsafe are
	      therefore	slightly faster, but unsafe: anything  can  happen  if
	      the program accesses an array or string outside of its bounds.

	      Identify	the  types  string and bytes,  thereby	making strings
	      writable.	For reasons of backward	compatibility, this is the de-
	      fault  setting  for the moment, but this will change in a	future
	      version of OCaml.

       -use-runtime runtime-name
	      Generate a bytecode executable file that can be executed on  the
	      custom   runtime	 system	  runtime-name,	  built	 earlier  with
	      ocamlc -make-runtime runtime-name.

       -v     Print the	version	number of the compiler and the location	of the
	      standard library directory, then exit.

	      Print all	external commands before they are executed, in partic-
	      ular invocations of the C	compiler and linker in	-custom	 mode.
	      Useful to	debug C	library	problems.

	      Compile  or link multithreaded programs, in combination with the
	      VM-level threads library described in The	OCaml user's manual.

       -vnum or	-version
	      Print the	version	number of the compiler	in  short  form	 (e.g.
	      "3.11.0"), then exit.

       -w warning-list
	      Enable,  disable,	or mark	as fatal the warnings specified	by the
	      argument warning-list.

	      Each warning can be enabled or disabled, and each	warning	can be
	      fatalor non-fatal.  If a warning is disabled, it isn't displayed
	      and doesn't affect compilation in	any way	(even if it is fatal).
	      If  a  warning  is enabled, it is	displayed normally by the com-
	      piler whenever the source	code triggers it.  If  it  is  enabled
	      and  fatal, the compiler will also stop with an error after dis-
	      playing it.

	      The warning-list argument	is a sequence of  warning  specifiers,
	      with  no separators between them.	 A warning specifier is	one of
	      the following:

	      +num   Enable warning number num.

	      -num   Disable warning number num.

	      @num   Enable and	mark as	fatal warning number num.

	      +num1..num2   Enable all warnings	between	num1 and num2  (inclu-

	      -num1..num2   Disable all	warnings between num1 and num2 (inclu-

	      @num1..num2   Enable and mark as fatal all warnings between num1
	      and num2 (inclusive).

	      +letter	 Enable	 the  set of warnings corresponding to letter.
	      The letter may be	uppercase or lowercase.

	      -letter	Disable	the set	of warnings corresponding  to  letter.
	      The letter may be	uppercase or lowercase.

	      @letter	 Enable	 and  mark as fatal the	set of warnings	corre-
	      sponding to letter.  The letter may be uppercase or lowercase.

	      uppercase-letter	 Enable	the set	of warnings  corresponding  to

	      lowercase-letter	  Disable the set of warnings corresponding to

	      The warning numbers are as follows.

	      1	   Suspicious-looking start-of-comment mark.

	      2	   Suspicious-looking end-of-comment mark.

	      3	   Deprecated feature.

	      4	   Fragile pattern matching: matching that  will  remain  com-
	      plete  even  if  additional constructors are added to one	of the
	      variant types matched.

	      5	   Partially applied function:	expression  whose  result  has
	      function type and	is ignored.

	      6	   Label omitted in function application.

	      7	   Method overridden without using the "method!" keyword

	      8	   Partial match: missing cases	in pattern-matching.

	      9	   Missing fields in a record pattern.

	      10   Expression on the left-hand side of a sequence that doesn't
	      have type	unit (and that is not a	function, see  warning	number

	      11   Redundant case in a pattern matching	(unused	match case).

	      12   Redundant sub-pattern in a pattern-matching.

	      13   Override of an instance variable.

	      14   Illegal backslash escape in a string	constant.

	      15   Private method made public implicitly.

	      16   Unerasable optional argument.

	      17   Undeclared virtual method.

	      18   Non-principal type.

	      19   Type	without	principality.

	      20   Unused function argument.

	      21   Non-returning statement.

	      22   Preprocessor	warning.

	      23   Useless record with clause.

	      24    Bad	module name: the source	file name is not a valid OCaml
	      module name.

	      25   Pattern-matching with all clauses guarded.

	      26   Suspicious unused variable: unused variable that  is	 bound
	      with let or as, and doesn't start	with an	underscore (_) charac-

	      27   Innocuous unused variable:  unused  variable	 that  is  not
	      bound  with let nor as, and doesn't start	with an	underscore (_)

	      28   A pattern contains a	constant constructor  applied  to  the
	      underscore (_) pattern.

	      29    A  non-escaped end-of-line was found in a string constant.
	      This may cause portability problems between Unix and Windows.

	      30   Two labels or constructors of the same name are defined  in
	      two mutually recursive types.

	      31   A module is linked twice in the same	executable.

	      32   Unused value	declaration.

	      33   Unused open statement.

	      34   Unused type declaration.

	      35   Unused for-loop index.

	      36   Unused ancestor variable.

	      37   Unused constructor.

	      38   Unused extension constructor.

	      39   Unused rec flag.

	      40   Constructor or label	name used out of scope.

	      41   Ambiguous constructor or label name.

	      42   Disambiguated constructor or	label name.

	      43   Nonoptional label applied as	optional.

	      44   Open	statement shadows an already defined identifier.

	      45    Open  statement  shadows  an already defined label or con-

	      46   Error in environment	variable.

	      47   Illegal attribute payload.

	      48   Implicit elimination	of optional arguments.

	      49   Missing cmi file when looking up module alias.

	      50   Unexpected documentation comment.

	      59   Assignment on non-mutable value.

	      60   Unused module declaration.

	      61   Unannotated unboxable type in primitive declaration.

	      The letters stand	for the	following sets of warnings.  Any  let-
	      ter not mentioned	here corresponds to the	empty set.

	      A	 all warnings

	      C	 1, 2

	      D	 3

	      E	 4

	      F	 5

	      K	 32, 33, 34, 35, 36, 37, 38, 39

	      L	 6

	      M	 7

	      P	 8

	      R	 9

	      S	 10

	      U	 11, 12

	      V	 13

	      X	 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 30

	      Y	 26

	      Z	 27

	      The		default		      setting		    is
	      -w +a-4-6-7-9-27-29-32..39-41-42-44-45-48-50-60.	  Note	  that
	      warnings 5 and 10	are not	always triggered, depending on the in-
	      ternals of the type checker.

       -warn-error warning-list
	      Mark as errors the warnings  specified  in  the  argument	 warn-
	      ing-list.	  The  compiler	 will  stop  with an error when	one of
	      these warnings is	emitted.  The warning-list has the same	 mean-
	      ing  as  for  the	 -w  option: a + sign (or an uppercase letter)
	      marks the	corresponding warnings as fatal, a - sign (or a	lower-
	      case  letter)  turns  them back into non-fatal warnings, and a @
	      sign both	enables	and marks as fatal the corresponding warnings.

	      Note: it is not recommended to use  the  -warn-error  option  in
	      production  code,	 because it will almost	certainly prevent com-
	      piling your program with later versions of OCaml when  they  add
	      new warnings or modify existing warnings.

	      The default setting is -warn-error -a+31 (only warning 31	is fa-

	      Show the description of all available warning numbers.

       -where Print the	location of the	standard library, then exit.

       - file Process file as a	file name, even	if it starts with a  dash  (-)

       -help or	--help
	      Display a	short usage summary and	exit.

       ocamlopt(1), ocamlrun(1), ocaml(1).
       The OCaml user's	manual,	chapter	"Batch compilation".



Want to link to this manual page? Use this URL:

home | help