InglésFrancésEspañol

Ad


icono de página de OnWorks

emcc - Online en la nube

Ejecute emcc en el proveedor de alojamiento gratuito de OnWorks a través de Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS

Este es el comando emcc que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.

PROGRAMA:

NOMBRE


emcc - Interfaz del compilador de Emscripten

DESCRIPCIÓN


archivo emcc [opciones] ...

La mayoría de las normal gcc / g ++ opciones seguirá puede para ejemplo:
--ayuda Mostrar esta información

--versión
Mostrar información de la versión del compilador

Opciones esa en modificado or nueva in emcc incluyen:
-O0 Sin optimizaciones (predeterminado)

-O1 Optimizaciones simples, incluidas asm.js, LLVM -O1 optimizaciones y sin tiempo de ejecución
aserciones o captura de excepciones de C ++ (para volver a habilitar la captura de excepciones de C ++, utilice -s
DISABLE_EXCEPTION_CATCHING = 0). (Para obtener detalles sobre los efectos de diferentes opciones
niveles, consulte apply_opt_level () en tools / shared.py y también src / settings.js.) Nota:
Las optimizaciones solo se realizan cuando se compila en JavaScript, no en intermedio
bitcode, * a menos que * compile con EMCC_OPTIMIZE_NORMALLY = 1 (no recomendado a menos que
¡Sabes lo que estas haciendo!)

-O2 As -O1, más el relooper (recreación en bucle), LLVM -O2 optimizaciones y

-s ALIASING_FUNCTION_POINTERS = 1

-O3 As -O2, además de optimizaciones peligrosas que pueden romper el código generado. Esto agrega

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

Esto no se recomienda en absoluto. Una mejor idea es probar cada uno de estos por separado en
arriba de -O2 para ver qué funciona. Consulte la wiki y src / settings.js (para -s opciones)
para obtener más información.

-s OPCIÓN = VALOR
Opción de generación de código JavaScript pasada al compilador emscripten. Para el
opciones disponibles, consulte src / settings.js Tenga en cuenta que para las opciones que son listas,
necesitan comillas en la mayoría de las conchas, por ejemplo

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

or

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

(sin los externos en ninguno de esos, obtendría un error)

También puede especificar un archivo desde el que se leerá el valor, por ejemplo,

-s DEAD_FUNCTIONS = @ / ruta / a / archivo

Los contenidos de / ruta / a / archivo se leerá, analizará JSON y se configurará en DEAD_FUNCTIONS
(para que el archivo pueda contener

["_func1", "func2"]

). Tenga en cuenta que la ruta debe ser absoluta, no relativa.

-g Utilice la información de depuración. Tenga en cuenta que lo necesita durante la última fase de compilación de
bitcode a JavaScript, o de lo contrario lo eliminaremos por defecto en -O1 y por encima. En
-O0, los números de línea se mostrarán en el código generado. En -O1 y arriba, el
optimizer elimina esos comentarios. Sin embargo, esta bandera tiene el efecto de
deshabilitar cualquier cosa que cause alteración o minificación de nombres (cierre o
registrar el pase).

- matrices-tipo
0: Sin matrices tipadas 1: matrices tipadas en paralelo 2: matrices tipadas compartidas (tipo C)
(Por defecto)

--llvm-opciones
0: sin optimizaciones LLVM (predeterminado en -O0) 1: -O1 Optimizaciones LLVM (por defecto en
-O1) 2: -O2 Optimizaciones LLVM 3: -O3 Optimizaciones LLVM (por defecto en -O2+)

--llvm-lto
0: Sin LLVM LTO (predeterminado en -O2 e inferior) 1: LLVM LTO (predeterminado en -O3) Nota: Si
Las optimizaciones LLVM no se ejecutan (consulte --llvm-opciones), establecerlo en 1 no tiene ningún efecto.

--cierre
0: sin compilador de cierre (predeterminado en -O2 y abajo) 1: Ejecute el compilador de cierre. Esta
reduce en gran medida el tamaño del código y, en algunos casos, puede aumentar la velocidad del tiempo de ejecución (aunque
también puede ocurrir lo contrario). Tenga en cuenta que la ejecución lleva tiempo y puede requerir algunos
cambios en el código. Esto se ejecuta de forma predeterminada en -O3.

En el modo asm.js, el cierre solo se usará en el código 'shell' alrededor del compilado
código (el código compilado será procesado por el minificador asm.js personalizado).

Nota: Si el compilador de cierre llega a una falta de memoria, intente ajustar JAVA_HEAP_SIZE en
el medio ambiente (por ejemplo, a 4096 m para 4 GB).

--js-transformar
se llamará en el código generado antes de que se optimice. Esto te permite
modificar el JavaScript, por ejemplo, agregando algún código o eliminando algún código, de una manera
que esas modificaciones se optimizarán junto con el código generado
adecuadamente. será llamado con el nombre de archivo del código generado como
parámetro; para modificar el código, puede leer los datos originales y luego agregarlos
o sobrescribirlo con los datos modificados. se interpreta como un espacio separado
lista de argumentos, por ejemplo, de "python processor.py" provocará una python
secuencia de comandos que se ejecutará.

--pre-js
Un archivo cuyo contenido se agrega antes del código generado. Esto se hace * antes *
optimización, por lo que se minificará correctamente si se ejecuta el compilador de cierre.

--post-js
Un archivo cuyo contenido se agrega después del código generado Esto se hace * antes *
optimización, por lo que se minificará correctamente si se ejecuta el compilador de cierre.

--archivo incrustado
Un archivo para incrustar dentro del JavaScript generado. El código compilado podrá
acceda al archivo en el directorio actual con el mismo nombre que se proporciona aquí. Así que si
tú lo haces --archivo incrustado dir / file.dat, entonces (1) dir / file.dat debe existir relativo a
donde ejecuta emcc, y (2) su código compilado podrá encontrar el archivo por
leyendo esa misma ruta, dir / file.dat. Si se pasa un directorio aquí, todo su
los contenidos se incrustarán.

--preload-archivo
Un archivo para precargar antes de ejecutar el código compilado de forma asincrónica. De lo contrario
similar a --archivo incrustado, excepto que esta opción solo es relevante al generar
HTML (utiliza XHR binarios asincrónicos) o JS que se utilizará en una página web. Si
aquí se pasa un directorio, se precargará todo su contenido. Archivos precargados
se almacenan en filename.data, donde filename.html es el archivo principal que está compilando
para. Para ejecutar su código, necesitará tanto el .html como el .data.

emcc ejecuta tools / file_packager.py para hacer el empaquetado real de incrustado y
archivos precargados. Puede ejecutar el empaquetador de archivos usted mismo si lo desea, consulte los documentos
dentro de ese archivo. Luego debe poner la salida del empaquetador de archivos en un emcc
--pre-js, para que se ejecute antes de su código compilado principal (o ejecútelo antes en
de alguna otra manera).

--compresión
Comprima tanto el código compilado como los archivos incrustados / precargados. debería ser un
triple,

, ,

donde native_encoder es un ejecutable nativo que comprime stdin a stdout (el
interfaz más simple posible), js_decoder es un archivo JavaScript que implementa un
decodificador, y js_name es el nombre de la función a llamar en el archivo del decodificador (que
debe recibir una matriz / matriz tipada y devolver una matriz / matriz tipada. Compresión
solo funciona al generar HTML. Cuando la compresión está activada, todos los archivos especificados para ser
precargados están comprimidos en un archivo grande, que recibe el mismo nombre que el
salida HTML pero con el sufijo .data.compress

--minificar
0: no minimice el espacio en blanco de JavaScript generado (predeterminado en -O0, -O1, o si
-g se usa)

1: minimiza los JavaScript generados

espacio en blanco (predeterminado en -O2+, asumiendo -g no se usa)

--separar
Divide el archivo javascript resultante en partes para facilitar la depuración. Esta opción
solo funciona si se genera Javascript (target -o .js). Archivos con función
las declaraciones deben cargarse antes que el archivo principal durante la ejecución.

Sin la opción "-g":

Crea archivos con declaraciones de funciones hasta el tamaño dado con el sufijo
"_functions.partxxx.js" y un archivo principal con el sufijo ".js".

Con la opción "-g":

Recrea la estructura de directorios de los archivos fuente de C y almacena la función
declaraciones en sus respectivos archivos C con el sufijo ".js". Si tal archivo
supera el tamaño indicado, se crean archivos con el sufijo ".partxxx.js". El principal
El archivo reside en el directorio base y tiene el sufijo ".js".

--unir Compila el código fuente utilizando el enfoque de enlaces "embind", que conecta C / C ++
y JS.

--ignore-dynamic-binding Normalmente, emcc tratará los enlaces dinámicos como
enlace estático, mediante el enlace en el código de la biblioteca dinámica. Esto falla si el
La misma biblioteca dinámica está vinculada más de una vez. Con esta opción, vinculación dinámica
se ignora, lo que permite que el sistema de compilación continúe sin errores. Sin embargo, tu
tendrá que vincularse manualmente a las bibliotecas compartidas más adelante.

--archivo-shell
El nombre de la ruta a un archivo HTML esqueleto que se usa al generar una salida HTML. La cáscara
el archivo utilizado debe tener este token en su interior: {{{SCRIPT_CODE}}} Tenga en cuenta que este
El argumento se ignora si se especifica un destino que no sea HTML mediante el -o .

--js-biblioteca
Una biblioteca de JavaScript para usar además de las de src / library_ * de Emscripten

-v Activa la salida detallada. Esto pasará -v a Clang, y también habilitar EMCC_DEBUG para
detalles de las operaciones de emcc

--jcaché
Utilice una caché de JavaScript. Esto está deshabilitado por defecto. Cuando está habilitado, emcc almacenará
los resultados de la compilación en un caché y verifique el caché al compilar más tarde,
algo parecido a lo que hace ccache. Esto permite compilaciones incrementales, donde se encuentre
compilando un programa grande pero solo modificó una pequeña parte para ser mucho más rápido
(a costa de más E / S de disco para accesos a la caché). Tenga en cuenta que necesita habilitar
--jcaché para cargar y guardar datos, por lo que debe habilitarlo en una compilación completa
para que se acelere una compilación incremental posterior (donde también la habilita).

El almacenamiento en caché funciona por separado en 4 partes de la compilación: 'pre' que es tipos y global
variables; esa información se alimenta luego en 'funcs' que son las funciones (que
paralelizamos), y luego 'publicar' que agrega información final basada en el
funciones (por ejemplo, necesitamos código de soporte long64). Finalmente, 'jsfuncs' son
Optimizaciones a nivel de JavaScript. Cada una de las 4 partes se puede almacenar en caché por separado, pero
tenga en cuenta que pueden afectarse entre sí: si vuelve a compilar un solo archivo C ++ que
cambia una variable global, por ejemplo, agrega, elimina o modifica una variable global, por ejemplo
agregando un printf o agregando una marca de tiempo en tiempo de compilación, entonces 'pre' no puede ser
cargado desde la caché. Y dado que la salida de 'pre se envía a' funcs 'y' post ',
también se invalidará, y solo se almacenará en caché 'jsfuncs'. Así que evita modificar
globales para permitir que el almacenamiento en caché funcione completamente.

Para solucionar el problema mencionado en el párrafo anterior, puede utilizar

emscripten_jcache_printf

al agregar debug printfs a su código. Esa función está especialmente preprocesada para
que no crea una cadena constante global para su primer argumento. Ver
emscripten.h para obtener más detalles. En particular, tenga en cuenta que ya debe tener un
llamar a esa función en su código * antes * de agregar una y hacer un incremento
construir, de modo que agregar una referencia externa (también una propiedad global) no
invalidar todo.

Tenga en cuenta que debe usar -g durante la etapa de vinculación (código de bits a JS), para que jcache
funciona (de lo contrario, la minificación JS puede confundirlo).

--limpiar cache
Limpia manualmente la caché de las bibliotecas del sistema emscripten compiladas (libc ++,
libc ++ abi, libc). Esto normalmente se maneja automáticamente, pero si actualiza llvm
in situ (en lugar de tener un directorio diferente para una nueva versión), el almacenamiento en caché
El mecanismo puede confundirse. Limpiar la caché puede solucionar problemas extraños relacionados con
incompatibilidades de caché, como clang que no se vincula con los archivos de la biblioteca. Esto también
borra otros datos almacenados en caché como jcache y el relooper bootstrapped. Después de la
la caché se borra, este proceso se cerrará.

- guardar-bc TRAYECTORIA
Al compilar en JavaScript o HTML, esta opción guardará una copia del código de bits
a la ruta especificada. El código de bits incluirá todos los archivos vinculados, incluidos
bibliotecas estándar y después de cualquier optimización de tiempo de enlace (si corresponde).

- archivo de inicio de memoria
Si está activado, generamos un archivo de inicialización de memoria separado. Esto es más eficiente
que almacenar los datos de inicialización de la memoria incrustados dentro de JavaScript como texto.
(el valor predeterminado es desactivado)

El archivo de destino, si se especifica (-o ), define lo que se generará:

.js
JavaScript

.html
HTML con JavaScript incrustado

.antes de Cristo
Código de bits LLVM (predeterminado)

.o
Código de bits LLVM (igual que .bc)

(Tenga en cuenta que si - archivo de inicio de memoria se utiliza, además de un archivo .js o .html que es
generado, también aparecerá un archivo .mem.)

El -c opción (que le dice a gcc que no ejecute el enlazador) hará que el código de bits LLVM sea
generado, ya que emcc solo genera JavaScript en la etapa final de vinculación de la construcción.

Los archivos de entrada pueden ser archivos de código fuente que Clang puede manejar (C o C ++), LLVM
bitcode en formato binario, o archivos de ensamblaje LLVM en formato legible por humanos.

emcc se ve afectado por varias variables de entorno. Para obtener más información, consulte la fuente de emcc
(busque 'os.environ').

emcc: destinos admitidos: llvm bitcode, javascript, NOT elf (a autoconf le gusta ver elf
arriba para habilitar el soporte de objetos compartidos)

DERECHOS DE AUTOR


Copyright © 2013 los autores de Emscripten (ver AUTHORS.txt) Esto es de código abierto y gratuito
software bajo la licencia MIT. NO hay garantía; ni siquiera por COMERCIABILIDAD o
APTITUD PARA UN PROPÓSITO PARTICULAR.

Use emcc en línea usando los servicios de onworks.net


Servidores y estaciones de trabajo gratuitos

Descargar aplicaciones de Windows y Linux

Comandos de Linux

Ad