#visual-studio-2017 #v8 #embedded-v8
#visual-studio-2017 #версия 8 #встроенный-версия 8
Вопрос:
Я потратил на это целый день, и, похоже, я не могу получить .lib файлы для сборки с помощью VS 2017. Я следил за документами V8 здесь:
Следование инструкциям работает, но в out каталоге я получаю программу командной строки версии 8, которая .lib НЕ работает с Visual Studio 2017.
неустранимая ошибка LNK1107: недопустимый или поврежденный файл: не удается прочитать по адресу 0x1422A
Я выполнил это, чтобы попытаться получить файлы сборки только для библиотек:
gn gen out/lib --args="v8_static_library=true v8_use_snapshot=true v8_use_external_startup_data=false v8_monolithic=true icu_use_data_file=false is_component_build=false is_debug=false"
Затем запустил это: ninja -C out/lib
И это был конечный результат:
ninja: Entering directory `out/lib'
[1632/1645] LINK cctest.exe cctest.exe.pdb
FAILED: cctest.exe cctest.exe.pdb
ninja -t msvc -e environment.x64 -- ../../../../third_party/llvm-build/Release Asserts/bin/lld-link.exe /nologo /OUT:./cctest.exe /PDB:./cctest.exe.pdb @./cctest.exe.rsp
lld-link: error: <root>: undefined symbol: mainCRTStartup
[1634/1645] LINK generate-bytecode-expectations.exe generate-bytecode-expectations.exe.pdb
ninja: build stopped: subcommand failed.
Мне кажется, я что-то упускаю, но на данный момент понятия не имею.
Ответ №1:
Хорошо, кажется, моей первой ошибкой было изменить приглашение на v8toolsdev и работать оттуда. «Обычные» шаги, которые я обнаружил, на самом деле работают должным образом только из корня исходного кода. В итоге v8toolsdevoutx64.release затем ninja -C out/x64.release v8 произошел сбой, потому что v8 по какой-то причине он не был принят в этой настройке.
Другая вещь, которую я сделал неправильно, это отредактировал args.gn файл напрямую и сохранил его. ПРАВИЛЬНЫЙ процесс должен выполняться gn args out.gnx64.release так, чтобы после сохранения И закрытия редактора он автоматически повторно генерировал / обновлял файлы. Скорее всего, изменение файла само по себе никак не повлияет, и вы запутаетесь, потому что ninja даже не увидите изменений.
Ошибка компоновщика о поврежденных файлах вызвана тем, что is_clang по умолчанию имеет значение true. Настройка is_clang=false устраняет эту ошибку. Это просто работает, я понятия не имею, почему; просто возьмите это и идите … 😉
Правильный способ из корня, который сработал для меня, это:
python toolsdevv8gen.py x64.release
python toolsdevv8gen.py ia32.release
python toolsdevv8gen.py x64.debug
python toolsdevv8gen.py ia32.debug
При этом будут выводиться файлы, которые могут быть скомпилированы в «v8out.gn » папка.
Совет: запустите «python toolsdevv8gen.py список», чтобы просмотреть список возможных конфигураций сборки.
Затем я обновил аргументы сборки:
gn args out.gnx64.release
Используя эти:
is_debug = false <-(or true for debug builds)
target_cpu = "x64"
is_component_build = false
v8_static_library = true
use_custom_libcxx = false
use_custom_libcxx_for_host = false
v8_use_external_startup_data = false <-(or true to use the bin startup files)
is_clang = false
И снова для 32-разрядной версии (конечно, изменив "x64" выше на "x86" ):
gn args out.gnia32.release
Затем повторил все вышеописанное для x64.debug и ia32.debug .
И скомпилировал их:
ninja -C out.gn/x64.debug v8
ninja -C out.gn/ia32.debug v8
ninja -C out.gn/x64.release v8
ninja -C out.gn/ia32.release v8
Visual Studio 2017 теперь снова создает и связывает мой проект с ними (это был старый проект, который я воскресил).
Примечание: Привязка к отладочным версиям библиотек версии 8 может выдавать ошибку, которая _ITERATOR_DEBUG_LEVEL не соответствует. Чтобы исправить это, я просто зашел в настройки проекта C ( Confiuration Properties->C/C ->Preprocessor->Preprocesor Definitions ) и добавил ;_ITERATOR_DEBUG_LEVEL=0 , чтобы он соответствовал.