ocamlc man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

OCAMLC(1)							     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 pro‐
       cesses them sequentially:

       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
       object code file x.cmo.	The file  x.cmi	 produced  corresponds	to  an
       interface 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
       libraries. 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
       dynamically 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
       directly, 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
       native-code  compiler  ocamlopt(1).   Thus,  it	behaves	 exactly  like
       ocamlc,	but  compiles  faster.	ocamlc.opt may not be available in all
       installations 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.
	      Additionally, 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 Dump  detailed  information  about the compilation (types, bind‐
	      ings, tail-calls, etc).  The information for file src.ml is  put
	      into  file  src.annot.   In  case	 of a type error, dump all the
	      information 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
	      interactively.

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

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

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

       -dllib -llibname
	      Arrange for the C shared	library	 dlllibname.so	to  be	loaded
	      dynamically 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 ident
	      This option is accepted for compatibility with ocamlopt(1) ;  it
	      does nothing.

       -g     Add  debugging  information  while  compiling  and linking. This
	      option 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
	      inferred types or their definitions) when compiling an implemen‐
	      tation (.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
	      extension is not .mli.

       -intf-suffix string
	      Recognize file names  ending  with  string  as  interface	 files
	      (instead 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.

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

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

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

       -noassert
	      Do not compile assertion checks.	Note  that  the	 special  form
	      assert 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 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.

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

       -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
	      external 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
	      default  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
	      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	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-debug-runtime,  then the d suffix is supported and gives a
	      debug version of the runtime.

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

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

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

       -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.	 For  reasons  of  backward compatibility, this is the
	      default 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.

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

       -vmthread
	      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‐
	      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 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
	      5).

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

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

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

	      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.

	      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.   Note  that warn‐
	      ings 5 and 10 are not always triggered, depending on the	inter‐
	      nals 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  (all  warnings  are  non-
	      fatal).

       -warn-help
	      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 (-)
	      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)
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net