CentOS 7.0 - man page for ocamlc (centos section 1)

Linux & Unix Commands - Search Man Pages

Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

OCAMLC(1)										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 standalone bytecode executable files.  These  exe-
       cutable 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:

       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 produces compiled object bytecode in the file x.cmo.

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

       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 bytecode 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 exe-
       cuted by the OCaml bytecode interpreter: the command ocamlrun(1).  If caml.out is the name
       of   the   file	 produced   by	 the   linking	 phase,  the  command  ocamlrun  caml.out
       arg1  arg2 ... argn executes the compiled code contained in caml.out, passing it as  argu-
       ments 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 man-
       ages to launch the bytecode interpreter 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.

       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 executable 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 automat-
	      ically  adds  back  the -custom, -cclib and -ccopt options as if they had been pro-
	      vided on the command line, unless the -noautolink option is given.

       -annot Dump detailed information about the compilation (types, bindings, 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.

	      Has been deprecated. Please use -annot instead.

       -c     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 use-
	      ful to compile modules 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 "custom runtime" mode
	      (see the -custom option). This causes the given C library to  be	linked	with  the

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

	      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, ocaml-
	      run(1).  In the custom runtime mode, the linker produces an output file  that  con-
	      tains  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  runtime"  mode enables linking OCaml code with
	      user-defined C functions.

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

       -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 cor-
	      responding to the -I option).  The -dllpath option simply stores dir  in	the  pro-
	      duced executable file, where ocamlrun(1) can find it and use it.

       -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 back-
	      traces 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 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  declara-
	      tions 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 -l xxx.  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.

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

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

       -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

	      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.

	      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.

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

	      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.

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

	      Cause the linker to produce a C object file instead of a bytecode 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  compiled	interface
	      (.cmi) that combines the object files given on the command line, making them appear
	      as sub-modules of the output .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  com-
	      piled.  If there are no compilation errors, the intermediate file is deleted after-
	      wards. 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)

	      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 meth-
	      ods, this flag is required to ensure future versions of the compiler will  be  able
	      to  infer  types	correctly,  even  if  internal	algorithms  change.  All programs
	      accepted in -principal mode are also accepted in the default mode  with  equivalent
	      types,  but  different binary signatures, 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 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-

       -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  sup-
	      ported and gives a debug version of the runtime.

	      The left-hand part of a sequence must have type unit.

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

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

       -use-runtime runtime-name
	      Generate a bytecode executable file that can be executed on the custom runtime sys-
	      tem 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 particular 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.

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

       -w warning-list
	      Enable,  disable,  or  mark  as errors the warnings specified by the argument warn-

	      Each warning can be enabled or disabled, and each warning can be marked (as  error)
	      or  unmarked.  If a warning is disabled, it isn't displayed and doesn't affect com-
	      pilation in any way (even if it is marked).  If a warning is enabled,  it  is  dis-
	      played  normally	by  the  compiler whenever the source code triggers it.  If it is
	      enabled and marked, the compiler will stop with an error after displaying the warn-
	      ings if the source code triggers 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 warning number num.

	      +num1..num2   Enable all warnings between num1 and num2 (inclusive).

	      -num1..num2   Disable all warnings between num1 and num2 (inclusive).

	      @num1..num2   Enable and mark 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 the set of warnings corresponding 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 syntax.

	      4     Fragile  pattern  matching:  matching that will remain complete even if addi-
	      tional constructors are added to one of the variant types matched.

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

	      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   Camlp4 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 (_) character.

	      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	(_)  pat-

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

	      The letters stand for the following sets of warnings.   Any  letter  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

	      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-9-27-29-32..39.  Note that warnings 5 and 10 are
	      not always triggered, depending on the internals of the type checker.

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

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

	      The default setting is -warn-error -a (none  of  the  warnings  is  treated  as  an

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

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

Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 05:32 PM.

Unix & Linux Forums Content Copyright©1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?