Компиляция кода C ++ для автономного Wasm с Emscripten приводит к .wasm, требующему определенных функций импорта - PullRequest
Новая
       23

Компиляция кода C ++ для автономного Wasm с Emscripten приводит к .wasm, требующему определенных функций импорта

1 голос
/ 22 сентября 2019

Я пытаюсь скомпилировать полную программу на C ++ для Wasm, используя Emscripten в качестве возможности обучения.Следующая команда создает полный действительный и работающий HTML + JS + Wasm: 

emcc main.cpp [...libraries] -Oz --std=c++17 -o output.html\
     -s "EXPORTED_FUNCTIONS=['_solve']"

Однако при попытке создать отдельный двоичный файл Wasm я получил следующую ошибку, а именно: 

emcc main.cpp [...libraries] -Oz --std=c++17 -o output.wasm\
     -s "EXPORTED_FUNCTIONS=['_solve']"

и создайте его экземпляр в JS: 

// `buffer` is pre-defined and contains the wasm binary in a typed array.
const module = new WebAssembly.Module(buffer);
// `imports` is an object of values and functions.
new WebAssembly.Instance(module, imports);

Функция импорта env: _assert должна быть вызываемой (оценка 'new WebAssembly.Instance (module, import)')

Проверка сгенерированного двоичного файла Wasm показывает, что ему требуется, чтобы среда хоста предоставляла довольно длинный список функций и переменных: 

  (import "env" "_abort" (func (;0;) (type 12)))
  (import "env" "___assert_fail" (func (;1;) (type 13)))
  (import "env" "abort" (func (;2;) (type 7)))
  (import "env" "_llvm_stacksave" (func (;3;) (type 21)))
  (import "env" "_llvm_stackrestore" (func (;4;) (type 7)))
  (import "env" "_getenv" (func (;5;) (type 2)))
  (import "env" "___setErrNo" (func (;6;) (type 7)))
  (import "env" "___unlock" (func (;7;) (type 7)))
  (import "env" "___syscall140" (func (;8;) (type 1)))
  (import "env" "___map_file" (func (;9;) (type 1)))
  (import "env" "___lock" (func (;10;) (type 7)))
  (import "env" "___cxa_uncaught_exceptions" (func (;11;) (type 21)))
  (import "env" "___cxa_throw" (func (;12;) (type 6)))
  (import "env" "___cxa_pure_virtual" (func (;13;) (type 12)))
  (import "env" "abortOnCannotGrowMemory" (func (;14;) (type 2)))
  (import "env" "_strftime_l" (func (;15;) (type 10)))
  (import "env" "_pthread_cond_wait" (func (;16;) (type 1)))
  (import "env" "_llvm_trap" (func (;17;) (type 12)))
  (import "env" "___cxa_allocate_exception" (func (;18;) (type 2)))
  (import "env" "_emscripten_resize_heap" (func (;19;) (type 2)))
  (import "env" "_emscripten_memcpy_big" (func (;20;) (type 3)))
  (import "env" "_emscripten_get_heap_size" (func (;21;) (type 21)))
  (import "env" "___wasi_fd_write" (func (;22;) (type 9)))
  (import "env" "___syscall91" (func (;23;) (type 1)))
  (import "env" "___syscall6" (func (;24;) (type 1)))
  (import "env" "__table_base" (global (;0;) i32))
  (import "env" "DYNAMICTOP_PTR" (global (;1;) i32))
  (import "global" "NaN" (global (;2;) f64))
  (import "global" "Infinity" (global (;3;) f64))
  (import "env" "memory" (memory (;0;) 256 256))
  (import "env" "table" (table (;0;) 725 725 funcref))

Я мог бы поручить Emscripten скомпилировать исходный код вполный пакет JS + Wasm или чистый файл JS, однако:

  • полный пакет JS + Wasm: Emscripten загружает двоичный файл WASM асинхронно, что проблематично в моей ситуации (точная причина выходит за рамкиэтого вопроса.)
  • Чистый файл JS: файл очень большой по размеру, и он больше не Wasm.

Мой вопрос: есть ли способ компилировать сТхоSE зависимости удалены или реализованы непосредственно в двоичном файле?Если нет, то есть ли в идеале облегченные библиотеки, которые могут обеспечить реализацию этих функций?

1 Ответ

1 голос
/ 22 сентября 2019

Во-первых, звучит так, что вы можете достичь своей цели, используя опцию -s WASM_ASYNC_COMPILATION=0.

Чтобы ответить на более широкий вопрос, файлы wasm, созданные в emscripten, довольно устали от кода библиотеки JS emscripten,Существует некоторая поддержка для создания автономных файлов wasm, и эта поддержка улучшается с течением времени, но общий случайный файл wasm в общем случае невозможен.

...