LLD-ссылка: ошибка: <root>: неопределенный символ: mainCRTStartup при сборке V8 - PullRequest
Новая
       53

LLD-ссылка: ошибка: <root>: неопределенный символ: mainCRTStartup при сборке V8

0 голосов
/ 03 марта 2019

Я потратил на это целый день, и я не могу получить файлы .lib для сборки с VS 2017. Я следовал документам V8 здесь:

https://v8.dev/docs/build

Следование инструкциям работает, но я получаю программу командной строки V8 в каталоге out и .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 Ответ

0 голосов
/ 04 марта 2019

Хорошо, похоже, моей первой ошибкой было изменение приглашения на v8\tools\dev\ и работа оттуда.«Нормальные» шаги, которые я нашел, на самом деле работают правильно только из корня источника.Я закончил с v8\tools\dev\out\x64.release, затем ninja -C out/x64.release v8 потерпел неудачу, потому что v8 не был принят в этой настройке по какой-то причине.

Другая вещь, которую я сделал, - это отредактировал файл args.gn напрямую и сохранил его.ПРАВИЛЬНЫЙ процесс должен запустить gn args out.gn\x64.release, чтобы после сохранения и закрытия редактора он автоматически заново генерировал / обновлял файлы.Скорее всего, изменение файла само по себе не повлияет, и вы запутаетесь, потому что ninja даже не увидит изменения.

Ошибка компоновщика в поврежденных файлах из-за того, что is_clang имеет значение trueдефолт.Установка is_clang=false исправляет эту ошибку.Это просто работает, я понятия не имею, почему;просто возьми его и иди ...;)

Правильный путь от корня, который у меня работал, таков: 

python tools\dev\v8gen.py x64.release
python tools\dev\v8gen.py ia32.release
python tools\dev\v8gen.py x64.debug
python tools\dev\v8gen.py ia32.debug

Это выдаст файлы, которые можно скомпилировать в "v8\ out.gn "folder.

Подсказка: Запустите" python tools \ dev \ v8gen.py list ", чтобы увидеть список возможных конфигураций сборки.

Далее Iобновил аргументы сборки: 

gn args out.gn\x64.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.gn\ia32.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 теперь строит и связывает мой проект сих снова сейчас (это был старый проект, который я воскресил).

Примечание. При связывании с отладочными версиями библиотек V8 может возникнуть ошибка, которая не соответствует _ITERATOR_DEBUG_LEVEL.Чтобы это исправить, я просто зашел в настройки проекта C ++ (Confiuration Properties->C/C++->Preprocessor->Preprocesor Definitions) и добавил ;_ITERATOR_DEBUG_LEVEL=0, чтобы оно совпадало.

...