emcc - Online in the Cloud

PROGRAM:

NAME

emcc - Emscripten compiler frontend

DESCRIPTION

emcc [options] file...

Most normal gcc/g++ options will work, for example:
--help Display this information

--version
Display compiler version information

Options that are modified or new in emcc include:
-O0 No optimizations (default)

-O1 Simple optimizations, including asm.js, LLVM -O1 optimizations, and no runtime
assertions or C++ exception catching (to re-enable C++ exception catching, use -s
DISABLE_EXCEPTION_CATCHING=0 ). (For details on the affects of different opt
levels, see apply_opt_level() in tools/shared.py and also src/settings.js.) Note:
Optimizations are only done when compiling to JavaScript, not to intermediate
bitcode, *unless* you build with EMCC_OPTIMIZE_NORMALLY=1 (not recommended unless
you know what you are doing!)

-O2 As -O1, plus the relooper (loop recreation), LLVM -O2 optimizations, and

-s ALIASING_FUNCTION_POINTERS=1

-O3 As -O2, plus dangerous optimizations that may break the generated code! This adds

-s FORCE_ALIGNED_MEMORY=1 -s DOUBLE_MODE=0 -s PRECISE_I64_MATH=0 --closure 1
--llvm-lto 1

This is not recommended at all. A better idea is to try each of these separately on
top of -O2 to see what works. See the wiki and src/settings.js (for the -s options)
for more information.

-s OPTION=VALUE
JavaScript code generation option passed into the emscripten compiler. For the
available options, see src/settings.js Note that for options that are lists, you
need quotation marks in most shells, for example

-s RUNTIME_LINKED_LIBS="['liblib.so']"

or

-s "RUNTIME_LINKED_LIBS=['liblib.so']"

(without the external "s in either of those, you would get an error)

You can also specify a file from which the value would be read, for example,

-s DEAD_FUNCTIONS=@/path/to/file

The contents of /path/to/file will be read, JSON.parsed and set into DEAD_FUNCTIONS
(so the file could contain

["_func1", "func2"]

). Note that the path must be absolute, not relative.

-g Use debug info. Note that you need this during the last compilation phase from
bitcode to JavaScript, or else we will remove it by default in -O1 and above. In
-O0, line numbers wil be shown in the generated code. In -O1 and above, the
optimizer removes those comments. This flag does however have the effect of
disabling anything that causes name mangling or minification (closure or the
registerize pass).

--typed-arrays <mode>
0: No typed arrays 1: Parallel typed arrays 2: Shared (C-like) typed arrays
(default)

--llvm-opts <level>
0: No LLVM optimizations (default in -O0) 1: -O1 LLVM optimizations (default in
-O1) 2: -O2 LLVM optimizations 3: -O3 LLVM optimizations (default in -O2+)

--llvm-lto <level>
0: No LLVM LTO (default in -O2 and below) 1: LLVM LTO (default in -O3) Note: If
LLVM optimizations are not run (see --llvm-opts), setting this to 1 has no effect.

--closure <on>
0: No closure compiler (default in -O2 and below) 1: Run closure compiler. This
greatly reduces code size and may in some cases increase runtime speed (although
the opposite can also occur). Note that it takes time to run, and may require some
changes to the code. This is run by default in -O3.

In asm.js mode, closure will only be used on the 'shell' code around the compiled
code (the compiled code will be processed by the custom asm.js minifier).

Note: If closure compiler hits an out-of-memory, try adjusting JAVA_HEAP_SIZE in
the environment (for example, to 4096m for 4GB).

--js-transform <cmd>
<cmd> will be called on the generated code before it is optimized. This lets you
modify the JavaScript, for example adding some code or removing some code, in a way
that those modifications will be optimized together with the generated code
properly. <cmd> will be called with the filename of the generated code as a
parameter; to modify the code, you can read the original data and then append to it
or overwrite it with the modified data. <cmd> is interpreted as a space-separated
list of arguments, for example, <cmd> of "python processor.py" will cause a python
script to be run.

--pre-js <file>
A file whose contents are added before the generated code. This is done *before*
optimization, so it will be minified properly if closure compiler is run.

--post-js <file>
A file whose contents are added after the generated code This is done *before*
optimization, so it will be minified properly if closure compiler is run.

--embed-file <file>
A file to embed inside the generated JavaScript. The compiled code will be able to
access the file in the current directory with the same name as given here. So if
you do --embed-file dir/file.dat, then (1) dir/file.dat must exist relative to
where you run emcc, and (2) your compiled code will be able to find the file by
reading that same path, dir/file.dat. If a directory is passed here, its entire
contents will be embedded.

--preload-file <name>
A file to preload before running the compiled code asynchronously. Otherwise
similar to --embed-file, except that this option is only relevant when generating
HTML (it uses asynchronous binary XHRs), or JS that will be used in a web page. If
a directory is passed here, its entire contents will be preloaded. Preloaded files
are stored in filename.data, where filename.html is the main file you are compiling
to. To run your code, you will need both the .html and the .data.

emcc runs tools/file_packager.py to do the actual packaging of embedded and
preloaded files. You can run the file packager yourself if you want, see docs
inside that file. You should then put the output of the file packager in an emcc
--pre-js, so that it executes before your main compiled code (or run it before in
some other way).

--compression <codec>
Compress both the compiled code and embedded/ preloaded files. <codec> should be a
triple,

<native_encoder>,<js_decoder>,<js_name>

where native_encoder is a native executable that compresses stdin to stdout (the
simplest possible interface), js_decoder is a JavaScript file that implements a
decoder, and js_name is the name of the function to call in the decoder file (which
should receive an array/typed array and return an array/typed array. Compression
only works when generating HTML. When compression is on, all filed specified to be
preloaded are compressed in one big archive, which is given the same name as the
output HTML but with suffix .data.compress

--minify <on>
0: Do not minify the generated JavaScript's whitespace (default in -O0, -O1, or if
-g is used)

1: Minify the generated JavaScript's

whitespace (default in -O2+, assuming -g is not used)

--split <size>
Splits the resulting javascript file into pieces to ease debugging. This option
only works if Javascript is generated (target -o <name>.js). Files with function
declarations must be loaded before main file upon execution.

Without "-g" option:

Creates files with function declarations up to the given size with the suffix
"_functions.partxxx.js" and a main file with the suffix ".js".

With "-g" option:

Recreates the directory structure of the C source files and stores function
declarations in their respective C files with the suffix ".js". If such a file
exceeds the given size, files with the suffix ".partxxx.js" are created. The main
file resides in the base directory and has the suffix ".js".

--bind Compiles the source code using the "embind" bindings approach, which connects C/C++
and JS.

--ignore-dynamic-linking Normally emcc will treat dynamic linking like
static linking, by linking in the code from the dynamic library. This fails if the
same dynamic library is linked more than once. With this option, dynamic linking
is ignored, which allows the build system to proceed without errors. However, you
will need to manually link to the shared libraries later on yourself.

--shell-file <path>
The path name to a skeleton HTML file used when generating HTML output. The shell
file used needs to have this token inside it: {{{ SCRIPT_CODE }}} Note that this
argument is ignored if a target other than HTML is specified using the -o option.

--js-library <lib>
A JavaScript library to use in addition to those in Emscripten's src/library_*

-v Turns on verbose output. This will pass -v to Clang, and also enable EMCC_DEBUG to
details emcc's operations

--jcache
Use a JavaScript cache. This is disabled by default. When enabled, emcc will store
the results of compilation in a cache and check the cache when compiling later,
something like what ccache does. This allows incremental builds - where you are
compiling a large program but only modified a small part of it - to be much faster
(at the cost of more disk IO for cache accesses). Note that you need to enable
--jcache for both loading and saving of data, so you must enable it on a full build
for a later incremental build (where you also enable it) to be sped up.

Caching works separately on 4 parts of compilation: 'pre' which is types and global
variables; that information is then fed into 'funcs' which are the functions (which
we parallelize), and then 'post' which adds final information based on the
functions (e.g., do we need long64 support code). Finally, 'jsfuncs' are
JavaScript-level optimizations. Each of the 4 parts can be cached separately, but
note that they can affect each other: If you recompile a single C++ file that
changes a global variable - e.g., adds, removes or modifies a global variable, say
by adding a printf or by adding a compile-time timestamp, then 'pre' cannot be
loaded from the cache. And since 'pre's output is sent to 'funcs' and 'post', they
will get invalidated as well, and only 'jsfuncs' will be cached. So avoid modifying
globals to let caching work fully.

To work around the problem mentioned in the previous paragraph, you can use

emscripten_jcache_printf

when adding debug printfs to your code. That function is specially preprocessed so
that it does not create a constant string global for its first argument. See
emscripten.h for more details. Note in particular that you need to already have a
call to that function in your code *before* you add one and do an incremental
build, so that adding an external reference (also a global property) does not
invalidate everything.

Note that you should use -g during the linking stage (bitcode to JS), for jcache to
work (otherwise, JS minification can confuse it).

--clear-cache
Manually clears the cache of compiled emscripten system libraries (libc++,
libc++abi, libc). This is normally handled automatically, but if you update llvm
in-place (instead of having a different directory for a new version), the caching
mechanism can get confused. Clearing the cache can fix weird problems related to
cache incompatibilities, like clang failing to link with library files. This also
clears other cached data like the jcache and the bootstrapped relooper. After the
cache is cleared, this process will exit.

--save-bc PATH
When compiling to JavaScript or HTML, this option will save a copy of the bitcode
to the specified path. The bitcode will include all files being linked, including
standard libraries, and after any link-time optimizations (if any).

--memory-init-file <on>
If on, we generate a separate memory initialization file. This is more efficient
than storing the memory initialization data embedded inside JavaScript as text.
(default is off)

The target file, if specified (-o <target>), defines what will be generated:

<name>.js
JavaScript

<name>.html
HTML with embedded JavaScript

<name>.bc
LLVM bitcode (default)

<name>.o
LLVM bitcode (same as .bc)

(Note that if --memory-init-file is used, then in addition to a .js or .html file that is
generated, a .mem file will also appear.)

The -c option (which tells gcc not to run the linker) will cause LLVM bitcode to be
generated, as emcc only generates JavaScript in the final linking stage of building.

The input file(s) can be either source code files that Clang can handle (C or C++), LLVM
bitcode in binary form, or LLVM assembly files in human-readable form.

emcc is affected by several environment variables. For details, view the source of emcc
(search for 'os.environ').

emcc: supported targets: llvm bitcode, javascript, NOT elf (autoconf likes to see elf
above to enable shared object support)

COPYRIGHT

Copyright © 2013 the Emscripten authors (see AUTHORS.txt) This is free and open source
software under the MIT license. There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

Use emcc online using onworks.net services