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

FreeBSD Manual Pages

  
 
  

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

NAME
       ocamlc -	The OCaml bytecode compiler

SYNOPSIS
       ocamlc [	options	] filename ...

       ocamlc.opt [ options ] filename ...

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

       If the interface	file x.mli exists, the implementation x.ml is  checked
       against the corresponding compiled interface x.cmi, which is assumed to
       exist.  If no interface x.mli is	provided, the compilation of x.ml 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
       x.ml.

       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	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 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.

OPTIONS
       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
	      option.

	      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-
	      sages.

       -annot Deprecated since 4.11. Please use	-bin-annot instead.

       -bin-annot
	      Dump  detailed  information  about the compilation (types, bind-
	      ings, tail-calls,	etc) in	binary	format.	 The  information  for
	      file  src.ml 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
	      -annot.

       -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  environment	variable "OCAML_COLOR" is considered if	-color
	      is not provided. Its values are auto/always/never	as above.

	      If -color	is not provided, "OCAML_COLOR" is not set and the  en-
	      vironment	 variable "NO_COLOR" is	set, then color	output is dis-
	      abled. Otherwise,	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.

       -error-style mode
	      Control  the  way	 error messages	and warnings are printed.  The
	      following	modes are supported:

	      short only print the error and its location;

	      contextual like "short", but also	display	the source code	 snip-
	      pet corresponding	to the location	of the error.

	      The default setting is contextual.

	      The  environment	variable  "OCAML_ERROR_STYLE" is considered if
	      -error-style is not provided. Its	values are short/contextual as
	      above.

       -compat-32
	      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.

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

       -config-var
	      Print  the  value	 of a specific configuration variable from the
	      -config output, then exit. If the	variable does not  exist,  the
	      exit code	is non-zero.

       -custom
	      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-
	      tions.

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

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

       -depend ocamldep-args
	      Compute dependencies, as ocamldep	would do.

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

       -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 A.ml 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-docs
	      Keep documentation strings in generated .cmi files.

       -keep-locs
	      Keep locations in	generated .cmi files.

       -labels
	      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.

       -linkall
	      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.

       -make-runtime
	      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.

       -match-context-rows
	      Set number of rows of context used during	pattern	matching  com-
	      pilation.	 Lower values cause faster compilation,	but less opti-
	      mized code. The default value is 32.

       -no-alias-deps
	      Do not record dependencies for module aliases.

       -no-app-funct
	      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.

       -noassert
	      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.

       -noautolink
	      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.

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

       -nostdlib
	      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 or -output-com-
	      plete-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.

       -opaque
	      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.

       -output-obj
	      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).

       -output-complete-obj
	      Same as -output-obj except when creating an object file where it
	      includes the runtime and autolink	libraries.

       -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.

       -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.

       -principal
	      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.

       -rectypes
	      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-
	      dencies.

       -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.

       -stop-after pass
	      Stop compilation after the given compilation pass. The currently
	      supported	passes are: parsing, typing.

       -safe-string
	      Enforce the separation between types  string and bytes,  thereby
	      making strings read-only.	This is	the default.

       -short-paths
	      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.

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

       -unboxed-types
	      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].

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

       -unsafe
	      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.

       -unsafe-string
	      Identify the  types  string and bytes,  thereby  making  strings
	      writable.	  This	is  intended for compatibility with old	source
	      code and should not be used with new software.

       -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.

       -verbose
	      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.

       -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
	      fatal or	non-fatal.   If	 a  warning is disabled, it isn't dis-
	      played and doesn't affect	compilation in any way (even if	it  is
	      fatal).	If  a  warning is enabled, it is displayed normally by
	      the compiler whenever the	source code triggers it.  If it	is en-
	      abled and	fatal, the compiler will also stop with	an error after
	      displaying it.

	      The warning-list argument	is either a mnemonic warning specifier
	      or a sequence of single character	warning	 specifiers,  with  no
	      separators  between them.	A mnemonic warning specifier is	one of
	      the following

	      +name   Enable warning name.

	      -name   Disable warning name.

	      @name   Enable and mark as fatal warning name.

	      A	single character 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-
	      sive).

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

	      @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
	      uppercase-letter.

	      lowercase-letter	  Disable the set of warnings corresponding to
	      lowercase-letter.

	      The warning numbers and mnemonic names are as follows.

	      1	[comment-start]
	      Suspicious-looking start-of-comment mark.

	      2	[comment-not-end]
	      Suspicious-looking end-of-comment	mark.

	      3
	      Deprecated feature.

	      4	[fragile-match]
	      Fragile pattern matching:	matching  that	will  remain  complete
	      even  if additional constructors are added to one	of the variant
	      types matched.

	      5	[ignored-partial-application]
	      Partially	applied	function: expression whose result has function
	      type and is ignored.

	      6	[labels-omitted]
	      Label omitted in function	application.

	      7	[method-override]
	      Method overridden	without	using the "method!" keyword.

	      8	[partial-match]
	      Partial match: missing cases in pattern-matching.

	      9	[missing-record-field-pattern]
	      Missing fields in	a record pattern.

	      10 [non-unit-statement]
	      Expression on the	left-hand side of a sequence that doesn't have
	      type unit	(and that is not a function, see warning number	5).

	      11 [redundant-case]
	      Redundant	case in	a pattern matching (unused match case).

	      12 [redundant-subpat]
	      Redundant	sub-pattern in a pattern-matching.

	      13 [instance-variable-override]
	      Override of an instance variable.

	      14 [illegal-backslash]
	      Illegal backslash	escape in a string constant.

	      15 [implicit-public-methods]
	      Private method made public implicitly.

	      16 [unerasable-optional-argument]
	      Unerasable optional argument.

	      17 [undeclared-virtual-method]
	      Undeclared virtual method.

	      18 [not-principal]
	      Non-principal type.

	      19 [non-principal-labels]
	      Type without principality.

	      20 [ignored-extra-argument]
	      Unused function argument.

	      21 [nonreturning-statement]
	      Non-returning statement.

	      22 [preprocessor]
	      Preprocessor warning.

	      23 [useless-record-with]
	      Useless record with clause.

	      24 [bad-module-name]
	      Bad module name: the source file name is not a valid OCaml  mod-
	      ule name.

	      25
	      Deprecated: now part of warning 8.

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

	      27 [unused-var-strict]
	      Innocuous	unused variable: unused	variable  that	is  not	 bound
	      with  let	nor as,	and doesn't start with an underscore (_) char-
	      acter.

	      28 [wildcard-arg-to-constant-constr]
	      A	pattern	contains a constant constructor	applied	to the	under-
	      score (_)	pattern.

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

	      30 [duplicate-definitions]
	      Two labels or constructors of the	same name are defined  in  two
	      mutually recursive types.

	      31 [module-linked-twice]
	      A	module is linked twice in the same executable.

	      32 [unused-value-declaration]
	      Unused value declaration.

	      33 [unused-open]
	      Unused open statement.

	      34 [unused-type-declaration]
	      Unused type declaration.

	      35 [unused-for-index]
	      Unused for-loop index.

	      36 [unused-ancestor]
	      Unused ancestor variable.

	      37 [unused-constructor]
	      Unused constructor.

	      38 [unused-extension]
	      Unused extension constructor.

	      39 [unused-rec-flag]
	      Unused rec flag.

	      40 [name-out-of-scope]
	      Constructor or label name	used out of scope.

	      41 [ambiguous-name]
	      Ambiguous	constructor or label name.

	      42 [disambiguated-name]
	      Disambiguated constructor	or label name.

	      43 [nonoptional-label]
	      Nonoptional label	applied	as optional.

	      44 [open-shadow-identifier]
	      Open statement shadows an	already	defined	identifier.

	      45 [open-shadow-label-constructor]
	      Open statement shadows an	already	defined	label or constructor.

	      46 [bad-env-variable]
	      Error in environment variable.

	      47 [attribute-payload]
	      Illegal attribute	payload.

	      48 [eliminated-optional-arguments]
	      Implicit elimination of optional arguments.

	      49 [no-cmi-file]
	      Missing cmi file when looking up module alias.

	      50 [unexpected-docstring]
	      Unexpected documentation comment.

	      51 [wrong-tailcall-expectation]
	      Function call annotated with an incorrect	@tailcall attribute

	      52 [fragile-literal-pattern]
	      Fragile constant pattern.

	      53 [misplaced-attribute]
	      Attribute	cannot appear in this context.

	      54 [duplicated-attribute]
	      Attribute	used more than once on an expression.

	      55 [inlining-impossible]
	      Inlining impossible.

	      56 [unreachable-case]
	      Unreachable  case	 in a pattern-matching (based on type informa-
	      tion).

	      57 [ambiguous-var-in-pattern-guard]
	      Ambiguous	or-pattern variables under guard.

	      58 [no-cmx-file]
	      Missing cmx file.

	      59 [flambda-assignment-to-non-mutable-value]
	      Assignment on non-mutable	value.

	      60 [unused-module]
	      Unused module declaration.

	      61 [unboxable-type-in-prim-decl]
	      Unannotated unboxable type in primitive declaration.

	      62 [constraint-on-gadt]
	      Type constraint on GADT type declaration.

	      63 [erroneous-printed-signature]
	      Erroneous	printed	signature.

	      64 [unsafe-array-syntax-without-parsing]
	      -unsafe used with	a preprocessor returning a syntax tree.

	      65 [redefining-unit]
	      Type declaration defining	a new '()' constructor.

	      66 [unused-open-bang]
	      Unused open! statement.

	      67 [unused-functor-parameter]
	      Unused functor parameter.

	      68 [match-on-mutable-state-prevent-uncurry]
	      Pattern-matching depending on mutable state prevents the remain-
	      ing arguments from being uncurried.

	      69 [unused-field]
	      Unused record field.

	      70 [missing-mli]
	      Missing interface	file.

	      71 [unused-tmc-attribute]
	      Unused @tail_mod_cons attribute

	      72 [tmc-breaks-tailcall]
	      A	tail call is turned into a non-tail call by the	@tail_mod_cons
	      transformation.

	      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-7-9-27-29-30-32..42-44-45-48-50-60-66..70.   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-
	      tal).

       -warn-help
	      Show the description of all available warning numbers.

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

       -with-runtime
	      Include the runtime system in the	generated program. This	is the
	      default.

       -without-runtime
	      The  compiler  does not include the runtime system (nor a	refer-
	      ence to it) in the generated program; it must be supplied	 sepa-
	      rately.

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

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

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

								     OCAMLC(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=ocamlc.opt&sektion=1&manpath=FreeBSD+Ports+14.3.quarterly>

home | help