CODEWITHSUNDEEP
visual-studio-2017v8embedded-v8
James Wilkins
James Wilkins

Reputation: 7367

lld-link: error: <root>: undefined symbol: mainCRTStartup when building V8

I've spent a whole day on this now and I can't seem to get the .lib files to build with VS 2017. I followed the V8 docs here:

https://v8.dev/docs/build

Following the instructions does work, but I end up with a V8 command line program in the out directory and .lib that do NOT work with Visual Studio 2017.

fatal error LNK1107: invalid or corrupt file: cannot read at 0x1422A

I executed this to try to get the build files for the libraries only:

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"

Then ran this: ninja -C out/lib

And this was the final result:

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.

I think I'm missing something, but I have no idea at the moment.

Upvotes: 0

Views: 4285

Answers (1)

James Wilkins
James Wilkins

Reputation: 7367

Ok, seems my first mistake was changing the prompt to v8\tools\dev\ and working from there. The "normal" steps I found actually only work properly from the root of the source. I ended up with v8\tools\dev\out\x64.release then ninja -C out/x64.release v8 failed because v8 was not accepted in this setup for some reason.

The other thing I did wrong was to edit the args.gn file directly and save it. The CORRECT process is to run gn args out.gn\x64.release so that after you save AND close the editor, it automatically re-generates/updates the files. Most likely changing the file has no effect on its own, and you'll get confused because ninja won't even see the changes.

The linker error about corrupt files is because is_clang is true by default. Setting is_clang=false fixes that error. It just works, I have no idea why; just take it and go ... ;)

The correct way, from the root that worked for me is:

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

This will output files that can be compiled in the "v8\out.gn" folder.

Tip: Run "python tools\dev\v8gen.py list" to see a list of possible build configurations.

Next I updated the build arguments:

gn args out.gn\x64.release

Using these:

 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

And again for the 32-bit version (changing "x64" above to "x86" of course):

gn args out.gn\ia32.release

Then repeated all the above for x64.debug and ia32.debug.

And compiled them:

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 now builds and links my project against them again now (was an old project I resurrected).

Note: Linking against debug versions of V8 libraries may give an error that _ITERATOR_DEBUG_LEVEL does not match. To fix this I simply went to the C++ project settings (Confiuration Properties->C/C++->Preprocessor->Preprocesor Definitions) and added ;_ITERATOR_DEBUG_LEVEL=0 so it matches.

Upvotes: 1

Related Questions